Re: [PATCH 55593] Add "SSLServerInfoFile" directive
On 13/10/13 10:29, Kaspar Brand wrote: On 11.10.2013 13:53, Dr Stephen Henson wrote: IMHO though there needs to be a way to be able to tie a directive to a certificate in mod_ssl anyway though. I'm surprised no one has needed to do that before. I'm not sure we really need this for mod_ssl, as configuring more than one cert per vhost is probably a very rare case (the number of non-RSA certs on public sites is extremely small - in the 2010 SSL Survey from Qualys e.g., a few more than 100 out of 600,000 were DSA [1]). If people deliberately want to go for something other than RSA, I would assume that they either omit the RSA cert completely, or set up a dedicated vhost for (EC)DSA. Kaspar, I don't think data from 2010 (or even data from today) should be assumed to be a reliable indicator of future use of non-RSA certs on public sites. AFAICT, interest (amongst the commercial CAs) in ECC certs continues to grow. Since a significant proportion (I estimate ~20%) of deployed clients will accept RSA server certs but not ECC server certs, I think that configuring both an ECC cert and an RSA cert on a single vhost may yet become popular! -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online
Re: uds support
On Oct 11, 2013, at 12:24 PM, Jim Jagielski wrote: > > Committed in r1531340 the above is implemented... kinda. > I instead went with > > http://localhost/foo/bar|sock:/var/run.s.sock > > which worked out just a bit cleaner... After playing around the above, I find that it's hard to come up with a consistent and logical (non-surprising) way to merge the 2 paths in the 2 uris... especially when you consider that ap_runtime_dir_relative() should really be applied as well. S I'm proposing that we simply drop the "sock:..." part and use 2 things as the "this is a UDS" trigger: 1. hostname is 'localhost' 2. the '|' is the last char of the URL eg: ajp://localhost/./rel/dir/foo.sock| http://localhost/var/tmp/s.sock| Comments?
RE: uds support
The original proposal look more intuitive. Especially the relative path in the ajp example looks hard to understand for the not so experienced. Regards Rüdiger > -Original Message- > From: Jim Jagielski > Sent: Montag, 14. Oktober 2013 15:08 > To: dev@httpd.apache.org > Subject: Re: uds support > > > On Oct 11, 2013, at 12:24 PM, Jim Jagielski wrote: > > > > Committed in r1531340 the above is implemented... kinda. > > I instead went with > > > > http://localhost/foo/bar|sock:/var/run.s.sock > > > > which worked out just a bit cleaner... > > After playing around the above, I find that it's hard to > come up with a consistent and logical (non-surprising) > way to merge the 2 paths in the 2 uris... especially > when you consider that ap_runtime_dir_relative() > should really be applied as well. > > S > > I'm proposing that we simply drop the "sock:..." > part and use 2 things as the "this is a UDS" > trigger: > > 1. hostname is 'localhost' > 2. the '|' is the last char of the URL > > eg: > > ajp://localhost/./rel/dir/foo.sock| > http://localhost/var/tmp/s.sock| > > Comments?
Re: uds support
Which one? sock://var/run/server.sock|http://localhost/foo/bar or http://localhost/foo/bar|sock:/var/run.s.sock I guess we could say that the path info for the "segment" that provides the communication scheme (http://localhost/... above), if any, is ignored. eg: http://localhost/|sock:./rel/dir/s.sock ajp://localhost/ignored/path|sock:/var/run/a.sock Heck, we could even do away w/ sock: and use file: which people understand has relative and abs paths, lacks host, etc... Plus, we avoid creating any "additional" scheme ;) On Oct 14, 2013, at 9:17 AM, Plüm, Rüdiger, Vodafone Group wrote: > The original proposal look more intuitive. Especially the relative path in > the ajp example > looks hard to understand for the not so experienced. > > Regards > > Rüdiger > >> -Original Message- >> From: Jim Jagielski >> Sent: Montag, 14. Oktober 2013 15:08 >> To: dev@httpd.apache.org >> Subject: Re: uds support >> >> >> On Oct 11, 2013, at 12:24 PM, Jim Jagielski wrote: >>> >>> Committed in r1531340 the above is implemented... kinda. >>> I instead went with >>> >>> http://localhost/foo/bar|sock:/var/run.s.sock >>> >>> which worked out just a bit cleaner... >> >> After playing around the above, I find that it's hard to >> come up with a consistent and logical (non-surprising) >> way to merge the 2 paths in the 2 uris... especially >> when you consider that ap_runtime_dir_relative() >> should really be applied as well. >> >> S >> >> I'm proposing that we simply drop the "sock:..." >> part and use 2 things as the "this is a UDS" >> trigger: >> >> 1. hostname is 'localhost' >> 2. the '|' is the last char of the URL >> >> eg: >> >>ajp://localhost/./rel/dir/foo.sock| >>http://localhost/var/tmp/s.sock| >> >> Comments? >
Re: [PATCH 55593] Add "SSLServerInfoFile" directive
> AFAICT, interest (amongst the commercial CAs) in ECC certs continues to > grow. Since a significant proportion (I estimate ~20%) of deployed clients > will accept RSA server certs but not ECC server certs, I think that > configuring both an ECC cert and an RSA cert on a single vhost may yet > become popular! +1
RE: uds support
> -Original Message- > From: Jim Jagielski > Sent: Montag, 14. Oktober 2013 15:45 > To: dev@httpd.apache.org > Subject: Re: uds support > > Which one? > > sock://var/run/server.sock|http://localhost/foo/bar > > or > > http://localhost/foo/bar|sock:/var/run.s.sock > > I guess we could say that the path info for the "segment" that > provides the communication scheme (http://localhost/... above), > if any, is ignored. > > eg: > > http://localhost/|sock:./rel/dir/s.sock > ajp://localhost/ignored/path|sock:/var/run/a.sock I like the above ones most. Regards Rüdiger
Re: uds support
On Oct 14, 2013, at 10:09 AM, Plüm, Rüdiger, Vodafone Group wrote: > > >> -Original Message- >> From: Jim Jagielski >> Sent: Montag, 14. Oktober 2013 15:45 >> To: dev@httpd.apache.org >> Subject: Re: uds support >> >> Which one? >> >> sock://var/run/server.sock|http://localhost/foo/bar >> >> or >> >> http://localhost/foo/bar|sock:/var/run.s.sock >> >> I guess we could say that the path info for the "segment" that >> provides the communication scheme (http://localhost/... above), >> if any, is ignored. >> >> eg: >> >> http://localhost/|sock:./rel/dir/s.sock >> ajp://localhost/ignored/path|sock:/var/run/a.sock > > I like the above ones most. > Any comments regarding using file: vs. sock: ??
Re: [PATCH 55593] Add "SSLServerInfoFile" directive
On 14.10.13 10:51, Rob Stradling wrote: > Kaspar, I don't think data from 2010 (or even data from today) should be > assumed to be a reliable indicator of future use of non-RSA certs on > public sites. "Past performance is not indicative of future performance", as they use to say in other industries, yes. Did the situation with Certicom's licensing terms for ECC cert issuance change recently? > AFAICT, interest (amongst the commercial CAs) in ECC certs continues to > grow. Since a significant proportion (I estimate ~20%) of deployed > clients will accept RSA server certs but not ECC server certs, I think > that configuring both an ECC cert and an RSA cert on a single vhost may > yet become popular! I'm not saying we should no longer support multiple certs per vhost (in fact, with my PoC patch, you can send as many certs to OpenSSL if you increase SSL_AIDX_MAX - though OpenSSL currently can't really cope with it)... what I'm saying is that I don't see a need for an additional per-cert directive. To support the "current cert" concept of OpenSSL for the SSL_CTX calls, we just need to make sure that we're applying the OpenSSLConfCmd directives (ServerInfoFile etc.) at the proper place. Kaspar
