Re: [RFC] Enable OCSP Stapling by default in httpd trunk
ove the SSLUseStapling directive closer to the cert settings, > and make people aware of the outgoing connections this will trigger) > >> Part of what makes the 2.4.x tangent is confusing is that sometimes your >> objections seem to be qualified on the assumption that 2.4.x would be >> updated. Can we please drop 2.4.x from this conversation? > > Will do, yes. When trunk becomes 2.6/3.0 one day (and a GA release), the > basic question remains, though: is it acceptable that configuring an SSL > certificate potentially triggers outgoing OCSP requests in mod_ssl, > without having been explicitly instructed to do so by an admin? My view > is still the same as in November 2014: admins should opt in for this > feature, not be forced to opt out. > >>> It's also for this reason that I'm not in favor of a global >>> "SSLUseStapling On", it should really be configured on a per-vhost basis. >> >> I don't follow. What does that help? With which attack vector does >> that improve the situation? > > The point I was trying to make is that stapling is a per-certificate > feature (not a global one like SSLRandomSeed, SSLSessionCache etc.), so > it would be best if the admin becomes aware of it when configuring the cert. > >>>> While I find the "not make accidental outgoing connections" argument >>>> compelling (though perhaps with a different word than "accidental") the >>>> server already takes actions that cause outgoing connections to services >>>> not explicitly configured (DNS), and these occasionally cause problems. >>> Are you referring to queries when doing PTR lookups for connecting >>> clients? I think that's one of the very reasons why "HostnameLookups >>> Off" was chosen for extra/httpd-default.conf. >> >> Not HostnameLookups; resolving ServerName at startup (configured or >> defaulted). > > Ok, but I wouldn't consider DNS as being implicitly configured - after > all, the resolvers are specified when network access on the OS level is > configured (and DNS queries are sent to nameservers which are hopefully > authoritative for lookups of hosts in the local net). > >>>> Is there a principle at stake which could be followed consistently across >>>> disparate features in how the server behaves a) with compiled in defaults >>>> and minimal config, or b) with default/recommended config? >>> The default configuration should not trigger unsolicited outgoing >>> queries to untrusted systems, for both a) and b), that's how I would >>> put it. >> >> Admin configures a certificate that has a domain name of attacker in the >> responder URI? DNS entry for domain name in responder URI is taken over >> to point to attacker? > > I was primarily trying to come up with a generic principle "which could > be followed consistently across disparate features", so I'm not sure if > considering specific attacks for the stapling case is the right way to > continue the discussion... as another example, take the "Version check > idea" thread from April 2015 [1] - even though there might not be an > immediate threat if it were enabled by default, I really hope that httpd > doesn't move into the direction of automatically enabling features > requiring outgoing connectivity (without the admin's explicit > instruction and consent). > >> So forgetting 2.4.x, are you vetoing changing the trunk default config >> to enable stapling, and are the criteria of the veto both >> >> 1. The default configuration should not trigger unsolicited outgoing >> queries to untrusted systems, for both a) and b), that's how I would put it. >> 2. Additionally, features enabled by default need to have sufficient >> coverage in the test framework. > > For GA releases, my position is that both criteria apply, yes. If it's > enabled in trunk, an alpha or a beta for getting broader testing exposure, > then the docs and release notes/announcement should prominently say so > (not only for OCSP stapling specifically, but in general for those > features which may trigger unsolicited outgoing connections). > > Kaspar > > > [1] > https://mail-archives.apache.org/mod_mbox/httpd-dev/201504.mbox/%3c7c89cdba-b463-415f-82da-ddd6ad88c...@jagunet.com%3E > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online
Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk
On 03/07/15 11:13, Plüm, Rüdiger, Vodafone Group wrote: snip Thanks for the detailed explanation. So yes OCSP stapling is really beneficial if it is possible for the server admin to set it up. But it likely requires additional configuration steps outside of httpd to make the OCSP responder reachable (like firewall clearances) and leads to otherwise strange slow responses if this is not prepared. Another obstacle with the current stapling code is that the connection to the OCSP responder of the CA needs to happen directly and cannot be done via a proxy. Hence I agree with Kaspar that it should be off by default. Given the current stapling code, that's fair enough. Is it feasible to engineer around these issues so that stapling could be enabled by default in some future httpd release? If not, what's the showstopper? Thanks. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
On 02/07/15 19:03, Ruediger Pluem wrote: snip Just to be sure I don't miss anything. This is not about disabling OCSP, its about disabling OCSP stapling by default. Maybe I have a wrong understanding of OCSP stapling, but to me stapling only provides performance improvements, not security improvements for the client as the client still could connect to the OCSP URL given in the cert directly and get the answer from there. If the response is stabled it does not need to (with the same level of security) and saves itself a roundtrip to the OCSP server of the CA and the OCSP server of the CA a request to process. Yes, the client _could_ connect to the OCSP URL given in the cert directly and get the answer from there. However, at least one major browser (Chrome) no longer does this, but it does process stapled OCSP responses. Even if we could ignore Chrome... There will always be some clients that cannot reach the CA's OCSP responder directly (due to connectivity issues at the client side), whereas the TLS servers that those clients connect to may well have better connectivity (and thus be able to staple OCSP responses that the client cannot obtain by any other means). Also, this isn't just about performance. If a client contacts an OCSP responder directly, it reveals to the CA that it is interested in a particular certificate. That's a far worse privacy leak than a TLS server contacting a CA's OCSP responder and revealing that it's interested in the status of its own certificate!! These are the same organization whose management are often those targeted by malware anyways. It's on them if they choose to ignore what few security measures are available to the less savvy end user. Again I don't get what this has to do with malware attacks on these organizations, but maybe my understanding of OCSP stapling is entirely wrong. Regards Rüdiger -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: TR of 2.2.13 [corresponding to Re: TR of 2.4.13]
s/2.2.13/2.2.30/ ? -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: mod_ssl patch: use new OpenSSL features to autofix cert chains
On 26/03/14 15:29, Emilia Kasper wrote: Wow, thanks for all the great feedback! On Wed, Mar 26, 2014 at 2:47 PM, Daniel Kahn Gillmor wrote: snip This is a pretty perverse situation, though, and perhaps the answer is that CA X just shouldn't do that kind of weird/chained reissuance over the key in Y. I've also done no certificate surveys to see if this sort of scenario has actually happened anywhere in the modern landscape. Cross-signing happens all the time but afaik the other way around, i.e., an intermediate Y' corresponding to a _newer_ root cert Y is cross-signed by some _older_ root cert Z. So an old client would usually know only Z and a newer client would know Z and Y (or even Y' - some clients directly trust intermediates these days). That's true in many cases, but... Comodo gained entry into the CA marketplace by purchasing one set of roots (from AddTrust) that were in the Netscape trust store, and another set of roots (from The USERTrust Network, aka UTN) that were in the Microsoft trust store. Neither set of roots were older or newer. UTN cross-certified AddTrust. A few years later we were able to get one of the AddTrust roots added to the Microsoft trust store. After that, it made more sense to have the cross-certification relationship the other way around, and so AddTrust cross-certified UTN. (Cue various cross-certification loop bugs in Mozilla's code, but I digress) Oh, BTW, bi-directional cross-certification also occurs in Bridge CA scenarios such as the Federal PKI. snip CT might be a good place to gather this information from -- are there plans to ensure that all intermediate CAs are logged publicly? No current plans for CT to require logging intermediates. But actually, if we go the autocorrect route then we should just implement AIA fetching. Modern certs should have a CA Issuers field in the AuthorityInformationAccess extension in them that the chain builder could follow recursively. I've now looked a bit more at the mod_ssl code and it's a bit of work but maybe not all that different from doing OCSP, really? So, we arrived at the point where AddTrust External CA Root became our primary root certificate, but we still needed to involve UTN in the cert chain in order to be trusted by old Windows platforms (i.e. Windows 2000, and XP boxes that have Automatic Root Update disabled). Noting that Windows clients do AIA fetching, we started including a carefully constructed pair of AIA-caIssuers URLs in many of the intermediate certs we issue and still use today. e.g. http://crt.comodoca.com/COMODOSSLCA.crt CA Issuers - URI:http://crt.usertrust.com/AddTrustExternalCARoot.p7c CA Issuers - URI:http://crt.usertrust.com/AddTrustUTNSGCCA.crt Most platforms trust AddTrust External CA Root, so they don't chase either of these AIA URLs. Old Windows boxes download the first URL (a PKCS#7 certs only bundle containing the self-signed AddTrust External CA Root root and a cross-cert issued to it by one of the UTN roots), and are able to build a chain up to AddTrust, or failing that, UTN. Even older Windows boxes don't support PKCS#7 AIA caIssuers URLs, so they then download the second URL and build a chain up to UTN. A correctly configured TLS server that uses one of our certs will send a cert chain terminating with AddTrust External CA Root. I do _not_ want mod_ssl to autocorrect this by following the AIA URL(s) and deciding to also send the cross-certificate issued by UTN. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: mod_ssl patch: use new OpenSSL features to autofix cert chains
On 26/03/14 16:46, Daniel Kahn Gillmor wrote: snip it doesn't even need to fetch the certificate itself, it could just make the big noisy error log say you should fetch the cert from AIAURL and append it to SSLCertificateChainFile AIAURL is supposed to be DER-encoded rather than Base64-encoded, so the user would need to convert it using openssl x509 -inform der -out before appending it to SSLCertificateChainFile. AIAURL is sometimes a PKCS#7 certs only bundle of multiple certs, all issued to the same Subject CA. The certs can be extracted using openssl pkcs7 -inform der -print_certs, but which one of those certs (if any) should the user append to SSLCertificateChainFile ? -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: mod_ssl patch: use new OpenSSL features to autofix cert chains
On 27/03/14 14:04, Daniel Kahn Gillmor wrote: On 03/27/2014 09:27 AM, Emilia Kasper wrote: snip As I said, I have low faith in admin intervention.. According to SSL pulse, 6% of Alexa top 200K sites serve an incomplete chain. You'd think they'd notice. I share your skepticism, but to be fair, most of the tools folks are faced with right now don't give them *any* pointers about what needs to be done, or even whether they've done the right thing or not. For most sysadmins (who have lots of different tasks to take care of that don't relate to the arcana of X.509 validation) the prospect of sorting this out is spend a couple hours on search engines reading random blog posts that disagree with each other to figure out what you might need to do, and when you're done you won't even be sure that you're done. Given this disappointing and frustrating scenario, i am not surprised that many people don't even bother trying. You're talking about improving the toolchains they have so that they get more concrete feedback about what they're doing and explicit suggestions about what needs to be done to fix the problems. i think that's great. BTW, a big +1 on wanting to do something to reduce the number of servers with misconfigured chains! -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: mod_ssl patch: use new OpenSSL features to autofix cert chains
On 27/03/14 17:11, Emilia Kasper wrote: snip Right. So this particular case could be handled by carefully constructing the shortest possible chain from all AIA information available (system store, p7c, crt). In that particular case, yes, I suppose so. However, our older AddTrust/UTN roots have also cross-certified some of our newer roots. So, in some cases, shortest possible chain (to a known, trusted root) would be too short! But I agree that it's gnarly, a bunch of ugly code, and hugely undeterministic (what if the .crt responds but the .p7c request errors out?). Indeed. Would you agree that it's safe to do a one-hop AIA-autocorrection for leaves only, i.e. certs with NO intermediates configured? My hunch is that this would fix the bulk of misconfigured chains while leaving the ugly cross-signing cornercases alone. I think it's probably safe in the sense that it wouldn't cause additional misconfiguration (and would sometimes cause correct configuration). But I'm in two minds about whether or not it's a good idea. IMHO, AIA chasing bears much of the blame for the problem we're trying to fix here. Why? Because when a site administrator tests their site in a browser that does AIA chasing (such as Internet Explorer), it works, so they don't notice and fix the misconfiguration. One-hop AIA-autocorrection might well make the configuration less broken (e.g. a missing intermediate is added), but still not correct (e.g. a missing cross-certificate is not added). Being less broken would mean that the remaining brokenness is less likely to be detected and corrected. So if the goal is to maximize the % of servers that are 100% correctly configured, one-hop AIA-autocorrection might actually be counterproductive. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: mod_ssl patch: use new OpenSSL features to autofix cert chains
On 27/03/14 16:45, Daniel Kahn Gillmor wrote: snip Do we have a robust, free tool that, given a single X.509 EE cert, can do automagic fetching and trying of all combinations of these things and produce a reasonable PEM-encoded SSLCertificateChainFile on stdout? If we had such a tool, then the detection code in mod_ssl could just encourage people to run that tool. I'm not aware of any existing tool that does this, but creating one has been on my todo list for a while. :-) I was thinking of putting the CA certificate discovery (using AIA fetching, CT Log parsing, ZMap scanning, or whatever), chain building and chain selection logic in a cloud-based service, rather than on the client. I think this would make it more robust and deterministic (i.e. you wouldn't have AIA fetches succeeding for some clients and failing for others) and it wouldn't require a client-side update whenever the (gnarly, ugly) chain selection logic needs tweaking. The client would simply HTTP(S) POST a certificate (or maybe just the AKID / Issuer Name) to the cloud-based service, and receive back a PEM-encoded SSLCertificateChainFile. Sound reasonable? (As it happens, I have a project that does most of this already... ;-) ) -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 14/10/13 17:28, Kaspar Brand wrote: 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? Not that I know of. But, with or without a licence from Certicom, it's gradually starting to happen. Symantec are already issuing ECC certs [1]. Here's one for urs.microsoft.com: -BEGIN CERTIFICATE- MIIDxjCCA2ugAwIBAgIQUbq+PtTzXy8rOAsfB6suITAKBggqhkjOPQQDAjB7MQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLDAqBgNVBAMTI1N5bWFudGVjIENs YXNzIDMgRUNDIDI1NiBiaXQgU1NMIENBMB4XDTEzMDkyMDAwMDAwMFoXDTE1MDkx OTIzNTk1OVowgYYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApXYXNoaW5ndG9uMRAw DgYDVQQHDAdSZWRtb25kMR4wHAYDVQQKDBVNaWNyb3NvZnQgQ29ycG9yYXRpb24x FDASBgNVBAsMC1NtYXJ0U2NyZWVuMRowGAYDVQQDDBF1cnMubWljcm9zb2Z0LmNv bTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABKRpJylWRGyj0IxBH+SMdRRioQd6 M6mSEDsnrnoLAeQmtJOOeGtafnrX4REkM9ZtsAWBWdynIAIFfBrcEb490+mjggHD MIIBvzA0BgNVHREELTArghF1cnMubWljcm9zb2Z0LmNvbYIWYmV0YS51cnMubWlj cm9zb2Z0LmNvbTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAU BggrBgEFBQcDAQYIKwYBBQUHAwIwQwYDVR0gBDwwOjA4BgpghkgBhvhFAQc2MCow KAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwHwYDVR0j BBgwFoAUdXGf/eTFGkqYm6v7wTqsTdTPb4wwTwYDVR0fBEgwRjBEoEKgQIY+aHR0 cDovL1NWUjI1NlNlY3VyZUVDQy1jcmwud3Muc3ltYW50ZWMuY29tL1NWUjI1NlNl Y3VyZUVDQy5jcmwwgZUGCCsGAQUFBwEBBIGIMIGFMDcGCCsGAQUFBzABhitodHRw Oi8vU1ZSMjU2U2VjdXJlRUNDLW9jc3Aud3Muc3ltYW50ZWMuY29tMEoGCCsGAQUF BzAChj5odHRwOi8vU1ZSMjU2U2VjdXJlRUNDLWFpYS53cy5zeW1hbnRlYy5jb20v U1ZSMjU2U2VjdXJlRUNDLmNlcjAKBggqhkjOPQQDAgNJADBGAiEAxdqO/Zo0L4tY +1VIXjyDBiWexXHo/LUwxJqWYK1DN/ECIQCcp+fXwMAOiv4OlvHjV3BrNuEdr93m WLuIyEC12xJ5uw== -END CERTIFICATE- 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 Ah, I see. Thanks for explaining. [1] http://www.symantec.com/connect/blogs/introducing-algorithm-agility-ecc-and-dsa -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
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! snip -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: Diffie-Hellman group parameters 1024 bit and Perfect Forward Secrecy
How about making ECDH parameters configurable from within Apache too? On 28/06/13 09:57, MikeM wrote: Hi, I agree that the configuration of DH parameters should be possible from within Apache. Ideally the configuration should allow the size of random DH Parameters to be chosen and also allow the user to provide a preconfigured DH Parameter file. This patch should be included into 2.2 and 2.4, and of course 2.5-dev :) Many thanks, Mike On 28/06/2013 08:46, Hanno Böck wrote: Hi, There has been lately some attention to perfect forward secrecy in TLS, mainly due to an article on netcraft: http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html What worries me is that apache still fixes the DH group size to 1024 bit. If one uses an RSA key with, e.g., 2048 bit, then using a DHE TLS cipher will actually downgrade the security of the connection. DLP or factoring-based public key cryptography with 1024 bit has been known to be potentially week for quite some time now. NIST recommended to phase out 1024 bit keys by 2010. (we don't have a key here, but the security of a DHE group with 1024 bit is equivalent to a 1024 bit DSA key) There's been a patch in bugzilla for a while to allow user-defined DH parameters, however it hasn't gotten any attention by apache developers yet: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 I'd like to ask apache devs to raise some attention to this issue. I think user-defined dh groups would be a good thing, but probably the default should also be raised to e.g. 2048 bit. cu, -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.
Enabling OCSP Stapling by default (was Re: mod_ssl ssl_util_stapling.c warnings)
On Wednesday 05 Jan 2011 10:03:19 Rob Stradling wrote: On Friday 24 December 2010 16:24:03 Igor Galić wrote: snip If we want to see more extensive testing in the field, then this is the right time to make 'On' the default. Steve, has Igor persuaded you? I was hoping to generate a bit more discussion and to reach consensus on the when question here on-list, but never mind. I've just filed Bug 50740 - Enable OCSP Stapling by default. Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: Enabling OCSP Stapling by default (was Re: mod_ssl ssl_util_stapling.c warnings)
On Wednesday 09 Feb 2011 09:39:36 Rob Stradling wrote: On Wednesday 05 Jan 2011 10:03:19 Rob Stradling wrote: On Friday 24 December 2010 16:24:03 Igor Galić wrote: snip If we want to see more extensive testing in the field, then this is the right time to make 'On' the default. Steve, has Igor persuaded you? I was hoping to generate a bit more discussion and to reach consensus on the when question here on-list, but never mind. I've just filed Bug 50740 - Enable OCSP Stapling by default. On a related note, I've also just filed Bug 50742 - Detect when the OpenSSL runtime library is vulnerable to CVE-2011-0014. I think it makes sense to *not* enable OCSP Stapling by default when a vulnerable version of OpenSSL is being used. Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: mod_ssl ssl_util_stapling.c warnings
On Friday 24 December 2010 16:24:03 Igor Galić wrote: snip If we want to see more extensive testing in the field, then this is the right time to make 'On' the default. Steve, has Igor persuaded you? Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: mod_ssl ssl_util_stapling.c warnings
On Wednesday 22 December 2010 16:11:21 Dr Stephen Henson wrote: On 22/12/2010 15:32, Rob Stradling wrote: On Friday 03 December 2010 10:31:24 Rob Stradling wrote: snip Would it be possible to make OCSP Stapling enabled by default (when the server certificate contains an OCSP Responder URL in the AIA extension) instead of disabled by default? (Perhaps SSLUseStapling could be replaced by SSLDisableStapling) Steve et al, Could you possibly spare a moment to answer this question? I was seeing if anyone else would comment on this first. It is of course technically possible. The OCSP stapling code requires an additional directive to enable an OCSP stapling cache: so this would break existing configuration files if enabled by default. Would it be possible to change the OCSP stapling code so that it will setup the OCSP stapling cache with some sensible default settings if the SSLStaplingCache directive is not specified anywhere in the config files? More significantly the code hasn't been tested extensively in the field so there may be problems that have yet to be uncovered. That's a fair point. My personal opinion would be to, at least initially, require an explicit directive to enable it and leave the option in future to have it enabled by default. Makes sense. tested extensively in the field isn't likely to happen until httpd 2.4.x is released and significant numbers of sites upgrade. Hopefully it would be safe to enable it by default in a fairly early 2.4.x point release. Anyone else have any thoughts on the matter? Steve. Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: mod_ssl ssl_util_stapling.c warnings
On Friday 03 December 2010 10:31:24 Rob Stradling wrote: snip Would it be possible to make OCSP Stapling enabled by default (when the server certificate contains an OCSP Responder URL in the AIA extension) instead of disabled by default? (Perhaps SSLUseStapling could be replaced by SSLDisableStapling) Steve et al, Could you possibly spare a moment to answer this question? Thanks. I just wonder how many webmasters would bother to add SSLUseStapling on to their config files, even though OCSP Stapling benefits all parties. I understand that Microsoft IIS 7.x enables OCSP Stapling by default. Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: mod_ssl ssl_util_stapling.c warnings
On Tuesday 30 November 2010 00:55:48 Dr Stephen Henson wrote: On 30/11/2010 00:03, Dr Stephen Henson wrote: On 29/11/2010 21:46, Guenter Knauf wrote: snip I think that we had some similar already in the past, and you suggested a change which was compatible with both 0.9.8 and 1.0.0 branches, but I cant recall ... Or do we need to cleanly solve this with some version-depent defines? See of the patch for bug #50121 resolves this for you. There's a slightly cleaner way of doing that r1040366 in trunk fixes it for me. Steve. Steve, thanks for cleaning and applying my patch. A quick question, if I may... Would it be possible to make OCSP Stapling enabled by default (when the server certificate contains an OCSP Responder URL in the AIA extension) instead of disabled by default? (Perhaps SSLUseStapling could be replaced by SSLDisableStapling) I just wonder how many webmasters would bother to add SSLUseStapling on to their config files, even though OCSP Stapling benefits all parties. I understand that Microsoft IIS 7.x enables OCSP Stapling by default. Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
