Re: Support for OpenSSL 1.1.0
On 09/02/2016 14:36, Rainer Jung wrote:
> Hi Steve,
>
> thanks a lot for your review and comments. More inline.
>
> Am 09.02.2016 um 13:34 schrieb Dr Stephen Henson:
>> On 09/02/2016 10:20, Rainer Jung wrote:
>>>
>>> 3) ssl_engine_ocsp.c
>>>
>>> In modssl_verify_ocsp() the following code accesses the struct member
>>> "valid",
>>> for which currently no accessor function exists in 1.1.0:
>>>
>>> 268 else if (cert->valid && X509_check_issued(cert,cert) == X509_V_OK) {
>>> 269 /* don't do OCSP checking for valid self-issued certs */
>>> 270 ap_log_cerror(APLOG_MARK, APLOG_TRACE2, 0, c,
>>> 271 "Skipping OCSP check for valid self-issued cert");
>>> 272 X509_STORE_CTX_set_error(ctx, X509_V_OK);
>>> 273 return 1;
>>> 274 }
>>>
>>>
>>
>> It's not clear what that code is supposed to do. The check isn't for
>> "self-issued" because that would just require comparing the subject and
>> issuer
>> names it is actually checking for a self signed certificate.
>
>> Is it supposed to be skipping OCSP checking for a trusted root?
>
> The svn log message says "Don't do OCSP checks for valid self-issued certs".
> The
> change was discussed here
>
> http://marc.info/?t=12921462952=1=2
>
> with some older discussion here
>
> http://marc.info/?t=11963686385=1=2
>
> As far as I get it, it is meant as an optimization to skip OCSP in cases where
> it isn't needed or useful. But I'm far from being an expert here. Kaspar, who
> introduced it originally formulated "prevents mod_ssl from doing unnecessary
> OCSP checks (valid self-issued certs, i.e. trust anchors configured through
> SSLCACertificate{File,Path})".
>
> I'll CC Kaspar directly.
>
OK it looks like at that point the certificate has been verified anyway so you
don't gain anything by checking cert->valid.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
Re: Support for OpenSSL 1.1.0
On 09/02/2016 10:20, Rainer Jung wrote:
>
> 3) ssl_engine_ocsp.c
>
> In modssl_verify_ocsp() the following code accesses the struct member "valid",
> for which currently no accessor function exists in 1.1.0:
>
> 268 else if (cert->valid && X509_check_issued(cert,cert) == X509_V_OK) {
> 269 /* don't do OCSP checking for valid self-issued certs */
> 270 ap_log_cerror(APLOG_MARK, APLOG_TRACE2, 0, c,
> 271 "Skipping OCSP check for valid self-issued cert");
> 272 X509_STORE_CTX_set_error(ctx, X509_V_OK);
> 273 return 1;
> 274 }
>
>
It's not clear what that code is supposed to do. The check isn't for
"self-issued" because that would just require comparing the subject and issuer
names it is actually checking for a self signed certificate.
Is it supposed to be skipping OCSP checking for a trusted root?
> 4) ssl_util_stapling.c
>
> In ssl_stapling_init_cert() there's a compiler warning:
> "passing argument 1 of 'sk_value' from incompatible pointer type
>expected 'const struct _STACK *' but argument is of type
>'struct stack_st_OPENSSL_STRING *'":
>
> 179cinf->uri = apr_pstrdup(p, sk_OPENSSL_STRING_value(aia, 0));
>
In ssl_private.h the checks like this:
#ifndef sk_OPENSSL_STRING_value
#define sk_OPENSSL_STRING_value sk_value
#endif
no longer work because stacks are now inline functions. If you put that block
round an appropriate #ifdef it should be fine.
I had a quick look at the changes and did notice that some of the direct
structure access (extensions, X509_NAME) is unnecessary in existing versions of
OpenSSL. So in some cases you don't need to only use them for 1.1: they'll work
in all versions of OpenSSL but it's only in 1.1 they are enforced.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
Re: PR 53435, r101624, mod_ssl: error strings can't be loaded again once?
On 11/11/2014 13:32, Jan Kaluža wrote: Hi, latest comment in PR 53435 shows that memory leak in mod_ssl which happens during graceful restarts can be caused by r101624. Since this commit is 11 years old, I wanted to ask people here, if following is still true with current OpenSSL: @@ -255,7 +255,11 @@ static apr_status_t ssl_cleanup_pre_config(void *data) #endif #endif ERR_remove_state(0); - ERR_free_strings(); + + /* Don't call ERR_free_strings here; ERR_load_*_strings only + * actually load the error strings once per process due to static + * variable abuse in OpenSSL. */ + /* * TODO: determine somewhere we can safely shove out diagnostics * (when enabled) at this late stage in the game: Last comment in PR 53435 showed that leaks disappeared after reverting this patch and it does not seem to break anything here. I just checked the sources and this was fixed in OpenSSL 0.9.7m just over 7 years ago... Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Odd - SSLCipherSuite
On 14/05/2014 10:23, Dirk-Willem van Gulik wrote: Now I must be getting rusty - we have in the config file SSLCipherSuite -ALL:ECDHE-RSA-AES256-SHA SSLProtocol -ALL +TLSv1.1 +TLSv1.2 +SSLv3 with the first resolving nicely with openssl ciphers -ALL:ECDHE-RSA-AES256-SHA to just ECDHE-RSA-AES256-SHA Unusual syntax though that should work. I'd normally just use the single ciphersuite name in the string: ECDHE-RSA-AES256-SHA So my assumption is that this server will insist on talking above - and = nothing else. And on the wire - if I observer the Server Hello I see: Secure Sockets Layer TLSv1.2 Record Layer: Handshake Protocol: Server Hello ... Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 = (0xc030) which is sort of what i expect. I wouldn't expect that as that isn't the single ciphersuite you've specified. However when I throw https://www.ssllabs.com/ssltest/analyze.html their analyzer at it - it seems to be quite able to convince the server = to say hello=92s with SSLv3 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: SSL 3.0 (0x0300) ... Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) or TLSv1.2 Record Layer: Handshake Protocol: Server Hello ... Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015) And so on*. I must be missing something very obvious here! Am I misunderstanding SSLCipherSuite or is there something specific about 1.2 which makes certain things mandatory and not under control of SSLCipherSuite? It looks like OpenSSL isn't receiving that cipher string properly or if it is being overridden by something else possible elsewhere in the config file. You can probe individual ciphersuites using s_client like this: openssl s_client -connect www.hostname.com:443 \ -cipher ECDHE-RSA-AES256-GCM-SHA384 If it isn't supported the connection shouldn't complete. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: mod_ssl patch: use new OpenSSL features to autofix cert chains
On 27/03/2014 13:01, Emilia Kasper wrote: On Wed, Mar 26, 2014 at 4:56 PM, Dr Stephen Henson shen...@opensslfoundation.com mailto:shen...@opensslfoundation.com wrote: On 26/03/2014 13:38, Emilia Kasper wrote: On Wed, Mar 26, 2014 at 1:11 PM, Dr Stephen Henson shen...@opensslfoundation.com mailto:shen...@opensslfoundation.com mailto:shen...@opensslfoundation.com mailto:shen...@opensslfoundation.com wrote: Well if you set SSL_BUILD_CHAIN_FLAG_IGNORE_ERROR then it will reorder the chain as best it can and just not fail if the chain is incomplete or broken in any other way. That's how the on the fly path building works at present. Personally I'd prefer it to return errors. That will catch other common problems like expiry of any certificate in the chain. Except it'll never get to checking expiry if there's no root cert. I think I'd prefer to ignore but log build errors - but that I can't do because the SSL_BUILD_CHAIN_FLAG_IGNORE_ERROR flag clears the error stack. I've updated it to not clear errors from the stack by default and to return 2 if there is a verification failure. That can be used to log a warning. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: mod_ssl patch: use new OpenSSL features to autofix cert chains
On 26/03/2014 11:11, Emilia Kasper wrote: Hi mod_ssl devs, I have a small patch for mod_ssl that uses new OpenSSL (=1.0.2) methods when available to automatically rebuild misconfigured certificate chains. Github pull request: https://github.com/apache/httpd/pull/7 Some of the common server chain misconfigurations are a) including the self-signed root certificate in the chain and b) missing an intermediate certificate in the chain. a) is bad because it bloats the handshake and b) is bad because the client can't always validate the chain. The patch fixes a) by sanity-checking the chain and chopping self-signed roots. I believe it's harmless to turn on by default as the rebuild step will either yield a valid chain or preserve the original configuration. I've no good idea how to reliably detect and fix missing intermediates but would be happy to try out any good suggestions. I think this is a good idea in principle. A major motivation for adding SSL_CTX_build_cert_chain to OpenSSL was to correct common chain configuration errors automatically (certificates in wrong order or additional bogus ones added) and to detect some other cases (chain not complete). Badly configured server chains have been a headache for clients for quite a while. A secondary motivation was to improve efficiency by avoiding the on the fly certificate chain building on each handshake and just build the chain once. There are some side effects with doing this though. If the server is correctly configured to exclude the root then the chain build will fail. The root is needed during path verification to see that the chain is complete. Some old on the fly configurations that place intermediate CAs in the trusted store are also likely to fail. Possible workaround is a way to turn off the checking an IReallyKnowWhatImDoing kind of thing which is disabled by default. Or just require affected users to reconfigure their servers. As for the patch itself. There could be a cleaner way to achieve the same thing. We're already optionally iterating through all certificates for OCSP staping using the 1.0.2 APIs so perhaps that can be adapted to perform a chain build sanity check at the same time. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: mod_ssl patch: use new OpenSSL features to autofix cert chains
On 26/03/2014 13:38, Emilia Kasper wrote: On Wed, Mar 26, 2014 at 1:11 PM, Dr Stephen Henson shen...@opensslfoundation.com mailto:shen...@opensslfoundation.com wrote: If the server is correctly configured to exclude the root then the chain build will fail. The root is needed during path verification to see that the chain is complete. Hmmm - it wasn't obvious from the doc that SSL_BUILD_CHAIN_FLAG_CHECK would fail this way but now that I think about it, I see you're right. This seems to be a limitation of X509_verify_cert and I'm not sure what to do about it. Would SSL_BUILD_CHAIN_FLAG_IGNORE_ERROR be too dangerous to set? We'd still be building a best-effort correct issuer chain, just no longer fully validating it. So I don't think it could mess up any good configurations (famous last words?) Well if you set SSL_BUILD_CHAIN_FLAG_IGNORE_ERROR then it will reorder the chain as best it can and just not fail if the chain is incomplete or broken in any other way. That's how the on the fly path building works at present. Personally I'd prefer it to return errors. That will catch other common problems like expiry of any certificate in the chain. If mod_ssl wants finer control on how the chain is built or better error reporting then it's always possible to use a customised function that calls X509_verify_cert manually. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [VOTE] Release Apache httpd 2.4.8 as GA
On 12/03/2014 12:29, Rainer Jung wrote: On 12.03.2014 11:37, Jim Jagielski wrote: At the very least, upgrading from 2.4.7 to 2.4.8 should not cause this much pain. I will let the vote run a bit more to gauge additional feedback, but my sense says that 2.4.8 will likely be revoked/dropped and 2.4.9 will be proposed which either (1) removes r1573360 or (2) fixes this bug. Agreed, if it were only about 1.0.1e vs. 1.0.1f it would be not that big an issue but since all Major versions seem to show the behavior and there's no easy workaround for 0.9.8 except upgrading to 1.x, I'd say we should implement the workaround suggested by Steve. Applied to trunk as r1576741. I've tried to keep the changes to the absolute minimum. I've tested OpenSSL 0.9.8y without this change and can reproduce the crash. It doesn't crash with this fix. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Turn off SSL session tickets
On 10/03/2014 10:22, Plüm, Rüdiger, Vodafone Group wrote: Reading the trunk documentation it seems possible to turn off SSL session tickets via SSLOpenSSLConfCmd Options -SessionTicket I assume there are no other options doing so on 2.2.x and 2.4.x, correct? A quick grep for the SSL_OP_NO_TICKET flag (which disables tickets) in mod_ssl came up empty so yes that is the only way. That should also work with 2.4.x but in both cases it requires OpenSSL 1.0.2. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [VOTE] Release Apache httpd 2.4.8 as GA
On 12/03/2014 17:39, William A. Rowe Jr. wrote: The fix was applied on Feb 11 2013. That would mean that official releases affected would be 0.9.8y, 1.0.0j and 1.0.1c. Any later official release should include the fix but we weren't planning to make any more 0.9.8 official releases though a 0.9.8 snapshot should include the fix. Perhaps a typo above? Or are we looking at several bugs? Rainer had specifically mentioned 1.0.1e as faulting. Yes sorry. It's all the same single bug. Checking through the versions: For 0.9.8 branches: 0.9.8y affected, only fixed in 0.9.8 snapshots. For 1.0.0 branches: 1.0.0k affected fixed in 1.0.0l For 1.0.1 branches: 1.0.1d, 1.0.1e affected fixed in 1.0.0f Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [VOTE] Release Apache httpd 2.4.8 as GA
On 11/03/2014 20:29, Rainer Jung wrote: On 11.03.2014 17:34, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.8 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.8 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience. I get a segfault during startup init on www.apache.org when using SSL. This didn't happen for r1570851. Candidate is r1573360. That server currently uses OpenSSL 1.0.1e. GDB: Program terminated with signal 11, Segmentation fault. #0 0x00010287a19a in ssl_set_cert_masks () from /usr/local/lib/libssl.so.8 (gdb) bt full #0 0x00010287a19a in ssl_set_cert_masks () from /usr/local/lib/libssl.so.8 No symbol table info available. #1 0x00010287a6f6 in ssl_get_server_send_pkey () from /usr/local/lib/libssl.so.8 Could be a known issue in OpenSSL 1.0.1e which is fixed in 1.0.1f. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [VOTE] Release Apache httpd 2.4.8 as GA
On 12/03/2014 00:30, Dr Stephen Henson wrote: The fix was applied on Feb 11 2013. That would mean that official releases affected would be 0.9.8y, 1.0.0j and 1.0.1c. Any later official release should include the fix but we weren't planning to make any more 0.9.8 official releases though a 0.9.8 snapshot should include the fix. OS specific versions of OpenSSL might not have included the fix. This is the actual diff: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=147dbb2fe3bead7a10 It looks like the only case this can happen is ssl_init_server_certs where an SSL structure is created, SSL_get_certificate called and then it is freed. If so then calling SSL_set_connect_state before the SSL_get_certificate call is a potential workaround. This works because the faulty code isn't used by SSL structures where ssl-server == 0 and SSL_set_connect_state does that, among other things. This is a bit of a hack because it's called on a server SSL structure. This would probably fail horribly if an attempt was made to use the SSL structure but in this case we're freeing it up immediately so this should hopefully not matter. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [VOTE] Release Apache httpd 2.4.8 as GA
On 11/03/2014 21:46, Gregg Smith wrote: On 3/11/2014 1:29 PM, Rainer Jung wrote: On 11.03.2014 17:34, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.8 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.8 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience. I get a segfault during startup init on www.apache.org when using SSL. This didn't happen for r1570851. Candidate is r1573360. I'm seeing this with OpenSSL 0.9.8y on Windows. Here are some more details of the bug in OpenSSL I *think* triggers this. The function SSL_get_certificate was modified in some versions of OpenSSL to return the certificate the server used instead of the current certificate it had done previously. This was to make OCSP stapling work with multiple configured certificates. Unfortunately a bug in the change mean it would crash if it was called before the server sent the certificate. Later versions of OpenSSL restored the original behaviour unless SSL_get_certificate was called inside the OCSP callback when it would return the certificate actually sent. The fix was applied on Feb 11 2013. That would mean that official releases affected would be 0.9.8y, 1.0.0j and 1.0.1c. Any later official release should include the fix but we weren't planning to make any more 0.9.8 official releases though a 0.9.8 snapshot should include the fix. OS specific versions of OpenSSL might not have included the fix. This is the actual diff: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=147dbb2fe3bead7a10 Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Fwd: [users@httpd] Performance drop in 2.4.7 versus 2.4.6
On 21/02/2014 13:02, Jeff Trawick wrote: Including dev@httpd.apache.org... Is anybody else seeing the same behavior? Looking at the documentation, 2.4.7 has gained some performance improvements, but I’m seeing something different on my end. Perhaps it's the increased DH parameter size? If it has increased from 1024 bits to 2048 that would have a significant effect. OpenSSL 1.0.2 s_client can help check this, if you do: openssl s_client -connect www.host.com:443 it says (among lots of other stuff): Server Temp Key: DH, bits Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Fwd: [users@httpd] Performance drop in 2.4.7 versus 2.4.6
On 21/02/2014 13:13, Dr Stephen Henson wrote: On 21/02/2014 13:02, Jeff Trawick wrote: Including dev@httpd.apache.org... Is anybody else seeing the same behavior? Looking at the documentation, 2.4.7 has gained some performance improvements, but I’m seeing something different on my end. Perhaps it's the increased DH parameter size? If it has increased from 1024 bits to 2048 that would have a significant effect. OpenSSL 1.0.2 s_client can help check this, if you do: openssl s_client -connect www.host.com:443 Correction, since the site is using OpenSSL 1.0.1f that command by itself may not be sufficient as ECDH is most likely to be used by default so it would need: openssl s_client -connect www.host.com:443 -cipher DH Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: 2.4.8 This Month
On 19/02/2014 15:08, Tom Browder wrote: On Wed, Feb 19, 2014 at 8:08 AM, Jim Jagielski j...@jagunet.com wrote: I'd like to shoot for a TR sometime next week... I'd like to TR and release 2.4.8 this month... Let's all take some time to: 1. See what in trunk should really be backported 2. Test and vote in STATUS backports I hope it fixes this (reported on users list): I configured httpd-2.4.7 successfully to use mod_ssl: ... --with-ssl=/usr/local/ssl/fips-2.0 and, during the build, it stops here: /usr/local/src/httpd-2.4.7/support/ab.c:509: undefined reference to `FIPS_rand_seed' /usr/local/src/httpd-2.4.7/support/ab.c:516: undefined reference to `FIPS_rand_seed' /usr/local/src/httpd-2.4.7/support/ab.c:522: undefined reference to `FIPS_rand_seed' That could be user error. The path /usr/local/ssl/fips-2.0 is the default install location of the FIPS module which isn't a complete version of OpenSSL. It should point to the location the FIPS capable OpenSSL is installed instead. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)
On 19/02/2014 18:37, Jeff Trawick wrote:
I think this is the trick...
+rc = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
+while (rc) {
+x = SSL_CTX_get0_certificate(ctx);
+if (x) {
+chain = NULL;
+SSL_CTX_get0_chain_certs(ctx, chain);
+if (chain) {
+for (i = 0; i sk_X509_num(chain); i++) {
+X509 *x = sk_X509_value(chain, i);
+/* do something */
+}
+}
+}
+rc = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
+}
I'm working on Certificate Transparency support for httpd; as part of
submitting
server certs with any necessary intermediate certs to CT logs I wanted to
extract them straight from the SSL_CTX so that it didn't matter how exactly
they
got there/were configured.
Unfortunately that wont work in all cases. There are several distinct ways CA
certificates can be configured.
In OpenSSL versions before 1.0.2 two ways existed. These had origins way back to
the SSLeay days.
One was a set of extra certificates which are shared amongst all the server
certificate types in an SSL_CTX. This is far from ideal because you could have
(for example) an RSA and a ECDSA certificate with different chains which you
couldn't configure using this method. It could also end up using the wrong chain
if the server is misconfigured. It also makes it impossible to have different
chains with different SSL structures sharing the same parent SSL_CTX.
On the plus side the set of certificates is configured only once and can be
retrieved by an application. I notice httpd can use this method.
The second method is used in the absence of any extra certificates. An attempt
is made to build a complete chain using the normal certificate verification
routine and trust store. This is done on the fly on each incoming connection
which is inefficient. It also uses the same certificate store used for client
certificate verification (which might not be ideal). It does however have the
advantage that it can handle different chains for different certificate types.
I *think* httpd can use this method too as it's done pretty much automatically.
In OpenSSL 1.0.2 this has been extended.
One method is the one which you used above. This supports distinct chains per
certificate type and per-SSL structure.
However for that to work it needs application support either explicitly by using
SSL_CTX_add0_chain_cert or via the use of SSL_CTX_use_cetificate_chain_file
which uses this transparently in OpenSSL 1.0.2. I just checked and httpd
currently doesn't use either of these but an enhancement to tidy up certificate
handling by Kaspar Brand does use SSL_CTX_use_certificate_chain_file.
That means getting a method that works in all cases is problematical.
You can use SSL_CTX_get_extra_chain_certs which retrieves the chain for the
current certificate or (if it is empty) the per-ctx chain.
That works for two cases above. If however the on the fly chain building is
performed it will fail.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)
On 19/02/2014 20:17, Jeff Trawick wrote:
On Wed, Feb 19, 2014 at 2:23 PM, Dr Stephen Henson
shen...@opensslfoundation.com mailto:shen...@opensslfoundation.com wrote:
On 19/02/2014 18:37, Jeff Trawick wrote:
I think this is the trick...
+rc = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
+while (rc) {
+x = SSL_CTX_get0_certificate(ctx);
+if (x) {
+chain = NULL;
+SSL_CTX_get0_chain_certs(ctx, chain);
+if (chain) {
+for (i = 0; i sk_X509_num(chain); i++) {
+X509 *x = sk_X509_value(chain, i);
+/* do something */
+}
+}
+}
+rc = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
+}
I'm working on Certificate Transparency support for httpd; as part of
submitting
server certs with any necessary intermediate certs to CT logs I wanted
to
extract them straight from the SSL_CTX so that it didn't matter how
exactly they
got there/were configured.
Unfortunately that wont work in all cases. There are several distinct
ways CA
certificates can be configured.
In OpenSSL versions before 1.0.2 two ways existed. These had origins way
back to
the SSLeay days.
One was a set of extra certificates which are shared amongst all the
server
certificate types in an SSL_CTX. This is far from ideal because you could
have
(for example) an RSA and a ECDSA certificate with different chains which
you
couldn't configure using this method. It could also end up using the
wrong chain
if the server is misconfigured. It also makes it impossible to have
different
chains with different SSL structures sharing the same parent SSL_CTX.
On the plus side the set of certificates is configured only once and can
be
retrieved by an application. I notice httpd can use this method.
The second method is used in the absence of any extra certificates. An
attempt
is made to build a complete chain using the normal certificate
verification
routine and trust store. This is done on the fly on each incoming
connection
which is inefficient. It also uses the same certificate store used for
client
certificate verification (which might not be ideal). It does however have
the
advantage that it can handle different chains for different certificate
types.
I *think* httpd can use this method too as it's done pretty much
automatically.
In OpenSSL 1.0.2 this has been extended.
One method is the one which you used above. This supports distinct chains
per
certificate type and per-SSL structure.
However for that to work it needs application support either explicitly
by using
SSL_CTX_add0_chain_cert or via the use of
SSL_CTX_use_cetificate_chain_file
which uses this transparently in OpenSSL 1.0.2. I just checked and httpd
currently doesn't use either of these but an enhancement to tidy up
certificate
handling by Kaspar Brand does use SSL_CTX_use_certificate_chain_file.
I need to make sure I understood this...
Let's say I have OpenSSL 1.0.2 and httpd trunk. httpd trunk has the (or
some) code to call SSL_CTX_use_certificate_chain_file. The code I posted
above will do the right thing, correct?
It also has some code that can call SSL_CTX_add_extra_chain_cert for which the
above wont work.
If I have OpenSSL 1.0.2 but httpd 2.4.x, there's no code to
call SSL_CTX_use_certificate_chain_file, so the code I posted won't work.
Correct.
That means getting a method that works in all cases is problematical.
You can use SSL_CTX_get_extra_chain_certs which retrieves the chain for
the
current certificate or (if it is empty) the per-ctx chain.
And this works with httpd 2.4.x, which doesn't have the call to
SSL_CTX_use_certificate_chain_file?
It also works with trunk where is call SSL_CTX_add_extra_chain_cert. So IMHO
that's the best strategy.
Not that you can get duplicate certificates using any of the techniques as the
same CA might issue more than one server certificate.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)
On 19/02/2014 20:17, Jeff Trawick wrote: On Wed, Feb 19, 2014 at 2:23 PM, Dr Stephen Henson shen...@opensslfoundation.com mailto:shen...@opensslfoundation.com wrote: That works for two cases above. If however the on the fly chain building is performed it will fail. Perhaps this is naive, but it may be reasonable for now to require that the log have access to the certificates required to perform the same on the fly chain building as the server, in the case where a chain is not configured. That sort of relates to a separate(ish) mechanism in 1.0.2. I've never been happy with the on the fly chain building. It's inefficient (building the chain on every connection), has no error mechanism if the chain cannot be completely built (which would be useful as an error indication: missing intermediate CA certificates in server configuration often cause problems) and it uses the verification store (which is also used for client authentication). I'd be happy if httpd moved to a more robust mechanism. In OpenSSL 1.0.2 there is a technique which might be usable here. You can set a separate chain store which is only used for chain building. You can also make an explicit call to SSL_CTX_build_cert_chain and it will build the chain internally for the current certificate and store it for later use. So to handle this typically you'd set up the chain store, call SSL_CTX_built_cert_chain once on every configured certificate and return an error condition on failure. The SSL_CTX would then have the chain set up correctly for each configured certificate in the correct order with no way misconfiguration could get it wrong. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: 2.4.8 This Month
On 19/02/2014 23:54, Tom Browder wrote: On Wed, Feb 19, 2014 at 11:21 AM, Tom Browder tom.brow...@gmail.com wrote: On Wed, Feb 19, 2014 at 10:53 AM, Dr Stephen Henson shen...@opensslfoundation.com wrote: On 19/02/2014 15:08, Tom Browder wrote: I configured httpd-2.4.7 successfully to use mod_ssl: ... That could be user error. The path /usr/local/ssl/fips-2.0 is the default install location of the FIPS module which isn't a complete version of OpenSSL. It should point to the location the FIPS capable OpenSSL is installed instead. Hm, I thought I tried that but I'll recheck and configure with: --with-ssl=/usr/local/ssl Bummer! When I did that, I get this: checking for OpenSSL... checking for user-provided OpenSSL base directory... /usr/local/ssl adding -I/usr/local/ssl/include to CPPFLAGS setting MOD_CFLAGS to -I/usr/local/ssl/include setting ab_CFLAGS to -I/usr/local/ssl/include adding -L/usr/local/ssl/lib to LDFLAGS setting MOD_LDFLAGS to -L/usr/local/ssl/lib checking for OpenSSL version = 0.9.7... OK adding -lssl to MOD_LDFLAGS adding -lcrypto to MOD_LDFLAGS adding -lrt to MOD_LDFLAGS adding -lcrypt to MOD_LDFLAGS adding -lpthread to MOD_LDFLAGS adding -ldl to MOD_LDFLAGS setting LIBS to -lssl -lcrypto -lrt -lcrypt -lpthread -ldl forcing ab_LDFLAGS to -L/usr/local/ssl/lib -lssl -lcrypto -lrt -lcrypt -lpthread -ldl checking openssl/engine.h usability... yes checking openssl/engine.h presence... yes checking for openssl/engine.h... yes checking for SSLeay_version... no checking for SSL_CTX_new... no checking for ENGINE_init... no checking for ENGINE_load_builtin_engines... no configure: WARNING: OpenSSL libraries are unusable yes setting MOD_SSL_LDADD to -export-symbols-regex ssl_module checking whether to enable mod_ssl... shared (reallyall) adding -I$(top_srcdir)/modules/ssl to INCLUDES So, is that a bad build for using mod_ssl or not? I will try the build now and report back. Well something is wrong there with it indicating OpenSSL version 0.9.7. If you intend to use the FIPS 2.0 module you must use OpenSSL 1.0.1. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: SSL and Apache Httpd 2.4.7 [was Re: 2.4.8 This Month]
On 20/02/2014 00:24, Tom Browder wrote: On Wed, Feb 19, 2014 at 7:09 PM, Dr Stephen Henson shen...@opensslfoundation.com wrote: On 19/02/2014 23:54, Tom Browder wrote: On Wed, Feb 19, 2014 at 11:21 AM, Tom Browder tom.brow...@gmail.com wrote: On Wed, Feb 19, 2014 at 10:53 AM, Dr Stephen Henson shen...@opensslfoundation.com wrote: On 19/02/2014 15:08, Tom Browder wrote: I configured httpd-2.4.7 successfully to use mod_ssl: ... That could be user error. The path /usr/local/ssl/fips-2.0 is the default install location of the FIPS module which isn't a complete version of OpenSSL. It should point to the location the FIPS capable OpenSSL is installed instead. Hm, I thought I tried that but I'll recheck and configure with: --with-ssl=/usr/local/ssl Bummer! When I did that, I get this: checking for OpenSSL... checking for user-provided OpenSSL base .. checking for OpenSSL version = 0.9.7... OK Well something is wrong there with it indicating OpenSSL version 0.9.7. If you intend to use the FIPS 2.0 module you must use OpenSSL 1.0.1. That doesn't mean its using 0.9.7. As a matter of fact my Debian installed OpenSSL is 1.0.1e, and Im trying to use 1.0.1.f FIPS. But now I get a failure to build Apache: /usr/local/ssl/lib/libcrypto.a(c_zlib.o): In function `bio_zlib_free': c_zlib.c:(.text+0x4d): undefined reference to `inflateEnd' c_zlib.c:(.text+0x69): undefined reference to `deflateEnd' /usr/local/ssl/lib/libcrypto.a(c_zlib.o): In function `bio_zlib_ctrl': c_zlib.c:(.text+0x24e): undefined reference to `deflate' c_zlib.c:(.text+0x338): undefined reference to `zError' So should I just kiss off Open SSL FIPS and Apache? What options did you use to configure OpenSSL? That looks like it has been configured to use a static link to zlib. Do you need zlib support? Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: SSL and Apache Httpd 2.4.7 [was Re: 2.4.8 This Month]
On 20/02/2014 00:24, Tom Browder wrote: On Wed, Feb 19, 2014 at 7:09 PM, Dr Stephen Henson shen...@opensslfoundation.com wrote: .. checking for OpenSSL version = 0.9.7... OK Well something is wrong there with it indicating OpenSSL version 0.9.7. If you intend to use the FIPS 2.0 module you must use OpenSSL 1.0.1. That doesn't mean its using 0.9.7. As a matter of fact my Debian installed OpenSSL is 1.0.1e, and Im trying to use 1.0.1.f FIPS. Oops, sorry my eyesight must be going... Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: SSL and Apache Httpd 2.4.7 [was Re: 2.4.8 This Month]
On 20/02/2014 02:21, Tom Browder wrote: On Wed, Feb 19, 2014 at 9:11 PM, William A. Rowe Jr. wmr...@gmail.com wrote: You could try tweaking the deployed /usr/local/lib/pkgconfig/openssl.pc file to include -lz in Libs: (just after -ldl), and then re-./configure I'll first see if I can get a good SSL to work. So far no build problems after I took out the zlib configure options with openssl/openssl-fips. I'll try my shiny new apache 2.4.7 and SSL tomorrow morning. The zlib is not that important to me at the moment--it just seemed a reasonable option when I first started this venture. Ah... there was a recent fix for this which hasn't yet appeared in an official OpenSSL release. This means that configuring OpenSSL with zlib wont create correct *.pc files. The zlib-dynamic option (which links to zlib at runtime in OpenSSL) should be OK though. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: SSL and Apache Httpd 2.4.7 [was Re: 2.4.8 This Month]
On 20/02/2014 02:40, William A. Rowe Jr. wrote: First insight, did you ./config openssl, or ./config shared? It seems near impossible to use static openssl. apr-util configure will fail since pkgconfig isn't consulted properly. httpd configure would also likely fail for redundant symbols. A static OpenSSL FIPS build will also have problems as statically built FIPS applications need to be linked with fipsld. It will appear to work until you try to enable FIPS mode and you'll then get a fatal signature does not match error. If you build and install a shared version of the FIPS capable OpenSSL this shouldn't happen. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: DH params and multiple certificates
On 19/02/2014 17:30, Falco Schwarz wrote: As of svn.apache.org/r1527295 standardized DH parameters were added to mod_ssl. If I understand docs correctly, the bit length is based on the RSA/DSA key. With the recent support of multiple certificates per VirtualHost it is possible to use an RSA and ECC certificate. When using RSA and ECC, the DH bit length is dependent on the certificate configured last, so: - if ECC is configured last, 1024 bit DH params are set (minimum) - if RSA is configured last, the DH params depend on the private keys bit length (it works) The ECC certificate should in any way be skipped and not taken into account when setting DH params. I think that's a consequence of how SSL_get_certificate works. You get the current certificate which is not necessarily the one the server actually uses. Ugly workaround for ephemeral DH ciphersuites... if the cipher is of the form *-RSA-* it's the RSA certificate and *-DSS-* it's the DSA one. No ciphersuites exist using ephemeral DH and ECDSA. We should probably have a way to set the current certificate in OpenSSL to the one the server used. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)
On 18/02/2014 20:06, Jeff Trawick wrote:
On Mon, Feb 3, 2014 at 6:21 AM, Dr Stephen Henson
shen...@opensslfoundation.com
mailto:shen...@opensslfoundation.com wrote:
On 02/02/2014 13:45, Kaspar Brand wrote:
On 01.02.2014 14:37, Dr Stephen Henson wrote:
I'm wondering how that could be avoided. Would a way to enumerate all
certificates in an SSL_CTX structure in OpenSSL help? Something like
SSL_CTX_get0_first_certificate() and SSL_CTX_get0_next_certificate().
That would
also set the current certificate at the same time in case applications
wanted to
inspect the private key or chain.
Yes, this sounds like a useful extension - not only for the issue at
hand (i.e. SSL_CONF and stapling initialisation), but as a general
mechanism for retrieving all certificates of an SSL_CTX.
Added now. The API is slightly different, but easy enough to use.
To iterate over all certificates in an SSL_CTX something like this will
do the
trick:
X509 *x;
int rv;
rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
while (rv)
{
X509 *x = SSL_CTX_get0_certificate(ctx);
rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
}
Steve.
Is the leaf certificate always first? (And/or maybe it is up to how the admin
configures it and it only works if the leaf is first?)
The APIs work this way with the OpenSSL 1.0.2 branch now?
TIA!
An SSL_CTX can have multiple server certificates associated with it
and the one used depends on the ciphersuite negotiated by the client.
The certificate you get from SSL_CTX_get0_certificate is the server certificate
which will always be a leaf certificate. You need different APIs to get the rest
of the chain (assuming one has been configured).
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
Re: mod_ssl-2.4.x-certkeyfile and OCSPStapling
On 05/02/2014 07:17, Kaspar Brand wrote: There are two ways to address the issue: either in mod_ssl, or in OpenSSL. I'm not sure which one is preferrable, but Mr. OpenSSL will hopefully tell us... (Steve: in theory, modifying the behavior of SSL_CTX_get_extra_chain_certs should be acceptable, given that only SSL_CTX_get0_chain_certs is documented, what do you think?) In OpenSSL a function being undocumented is no guarantee something wont call it ;-) It's not totally clear cut. With that change an application can no longer obtain the extra_chain_certs only and get NULL if there aren't any. However an application which is explicitly using per-certificate chains shouldn't be using the extra_chain_certs anyway. OTOH an existing application could uses SSL_CTX_use_certificate_chain_file and then try to retrieve extra chain certificates using SSL_CTX_get_extra_chain_certs. With the 1.0.2 changes to SSL_CTX_use_certificate_chain_file that would fail in 1.0.2 without that change. On balance I think that change should go in OpenSSL. I'll hear soon enough if it breaks anything... Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: mod_ssl-2.4.x-certkeyfile and OCSPStapling
On 05/02/2014 16:44, Falco Schwarz wrote: I assume that you are using (a snapshot of) OpenSSL 1.0.2, is that correct? Yes, I was using a nightly snapshot of OpenSSL 1.0.2 I've just added this though in a slightly different way. Please test the next snapshot or just pull the latest 1.0.2 branch from git. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: mod_ssl-2.4.x-certkeyfile and OCSPStapling
On 05/02/2014 18:32, Falco Schwarz wrote: I've just added this though in a slightly different way. Please test the next snapshot or just pull the latest 1.0.2 branch from git. Just pulled the latest 1.0.2 branch from git and recompiled OpenSSL / httpd. I cannot get Stapling to work, though. 2014-02-05 18:52:56 foo.bar [mpm_prefork|notice] AH00169: caught SIGTERM, shutting down 2014-02-05 18:53:01 foo.bar [ssl|error] AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate! 2014-02-05 18:53:01 foo.bar [ssl|error] AH: Unable to configure certificate foo.bar:443:0 for stapling 2014-02-05 18:53:01 foo.bar [ssl|error] AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate! 2014-02-05 18:53:01 foo.bar [ssl|error] AH: Unable to configure certificate foo.bar:443:0 for stapling + if (parg == NULL larg == 0) + *(STACK_OF(X509) **)parg = ctx-cert-key-chain; In theory, I cannot find an error in your change though. Kaspar, do you have an idea? Ugh, messed up. Should be fixed now. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)
On 02/02/2014 13:45, Kaspar Brand wrote:
On 01.02.2014 14:37, Dr Stephen Henson wrote:
I'm wondering how that could be avoided. Would a way to enumerate all
certificates in an SSL_CTX structure in OpenSSL help? Something like
SSL_CTX_get0_first_certificate() and SSL_CTX_get0_next_certificate(). That
would
also set the current certificate at the same time in case applications
wanted to
inspect the private key or chain.
Yes, this sounds like a useful extension - not only for the issue at
hand (i.e. SSL_CONF and stapling initialisation), but as a general
mechanism for retrieving all certificates of an SSL_CTX.
Added now. The API is slightly different, but easy enough to use.
To iterate over all certificates in an SSL_CTX something like this will do the
trick:
X509 *x;
int rv;
rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
while (rv)
{
X509 *x = SSL_CTX_get0_certificate(ctx);
rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
}
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS
On 01/02/2014 07:43, Kaspar Brand wrote: Steve, I'm using this opportunity for a short reminder about [1] - any comments about that? Should we try to get this into 2.4.8? Kaspar [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201401.mbox/%3c52cc3c0d.1030...@velox.ch%3E IMHO, yes. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS
On 01/02/2014 07:43, Kaspar Brand wrote: Steve, I'm using this opportunity for a short reminder about [1] - any comments about that? Should we try to get this into 2.4.8? On the subject of reminders and SSL_CONF. The code that handles SSL_CONF has something which manually checks for the Certificate command in order to handle stapling initialisation. Ideally that should be avoided with SSL_CONF because in future additional commands might be added to SSL_CONF which can affect certificates too and possibly multiple certificates simultaneously (e.g. imagine something loading several certificates and keys from a single source). Those would then have to be manually added to any application and one of the aims of SSL_CONF is to avoid the need to keep modifying applications to handle (some) new functionality. I'm wondering how that could be avoided. Would a way to enumerate all certificates in an SSL_CTX structure in OpenSSL help? Something like SSL_CTX_get0_first_certificate() and SSL_CTX_get0_next_certificate(). That would also set the current certificate at the same time in case applications wanted to inspect the private key or chain. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS
On 30/01/2014 18:25, Kaspar Brand wrote: On 29.01.2014 19:15, Graham Leggett wrote: On 29 Jan 2014, at 16:24, kbr...@apache.org wrote: URL: http://svn.apache.org/r1562500 Log: propose SSLCertificate[Key]File/SSLCertificateChainFile overhaul for mod_ssl Would it be possible to do the same for the SSLProxy* directives? I think so. Without having looked at the details of the current implementation, switching to OpenSSL's standard calls for loading certs and keys (SSL_CTX_use_*_file) should be possible for the SSL client case as well. Given that SSLProxyMachineCertificateFile, SSLProxyMachineCertificateChainFile and SSLProxyMachineCertificatePath are global-level-only directives, and that there is no SSLProxyMachineCertificateKeyFile directive right now, it would probably be a somewhat more intrusive change, compared to what has been done for the server-side part so far. I wasn't sure of the details of the current implementation either. Would it be appropriate to have SSL_CONF usable with SSLProxy* too? Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On 05/01/2014 09:00, Kaspar Brand wrote: On 03.01.2014 23:51, Dr Stephen Henson wrote: On 28/12/2013 13:34, Kaspar Brand wrote: FYI: in r1553824 (which I just committed to trunk), I'm now manually shuffling things around to support per-cert chains - but would happily drop the #if defined(SSL_CTX_set1_chain)-enclosed code if you decide to adapt SSL_CTX_use_certificate_chain_file in 1.0.2. Now done for OpenSSL master and 1.0.2 branches. Thanks, I have removed the code in r1555463 therefore. Assuming that the release of 1.0.2 isn't too far away by now, I have added a backport proposal for 2.4.x. Votes/reviews welcome. (And while I have your attention: could you perhaps have a look at OpenSSL's PRs #3178 and #3183? Both would help in improving SNI-based configurations.) OK I'll have a look at those. One the subject of 1.0.2 would it be appropriate to set auto ecdh parameter selection as the default in mod_ssl where supported? As things stand one single curve can be set (with default P-256) and it's an all or nothing choice, with auto parameter selection the highest priority curve supported by both sides is used. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On 28/12/2013 13:34, Kaspar Brand wrote: On 18.11.2013 18:42, Kaspar Brand wrote: On 18.11.2013 15:38, Dr Stephen Henson wrote: For OpenSSL 1.0.2 this limitation is removed and you can have different chains for each certificate type (and for SSL structures too) and it just uses the right one. This uses the function SSL_CTX_add1_chain_cert which adds a certificate to the chain for the current certificate. I *could* change SSL_CTX_use_certificate_chain_file to use SSL_CTX_add1_chain_cert instead of SSL_CTX_add_extra_chain_cert or perhaps have a different function. I'm always cautious about changing the behaviour of existing functions though as the most innocent change will usually break *something*, though I can't see how it can in this case. I would be in favor this change for 1.0.2 - to me that would be more like a fix of SSL_CTX_use_certificate_chain_file than a change in behavior, actually. FYI: in r1553824 (which I just committed to trunk), I'm now manually shuffling things around to support per-cert chains - but would happily drop the #if defined(SSL_CTX_set1_chain)-enclosed code if you decide to adapt SSL_CTX_use_certificate_chain_file in 1.0.2. Now done for OpenSSL master and 1.0.2 branches. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 03/01/2014 19:31, Jeff Trawick wrote: Support for ServerInfoFile still isn't in SSL_CONF_cmd()/SSL_CONF_cmd_value_type() in OpenSSL master or the 1.0.2 branch, right? (IOW, SSLOpenSSLConfCmd ServerInfoFile info1.pem is the planned interface in mod_ssl but not yet workable?) Or maybe I'm not looking at the right place in OpenSSL. I just added it to the OpenSSL master branch. Let me know if you have any problems. I'll backport it to 1.0.2 before release. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
On 24/12/2013 11:58, Yann Ylavic wrote: According to http://mail-archives.apache.org/mod_mbox/httpd-dev/200806.mbox/%3c48592955.2090...@velox.ch%3E, the (great) analyse Kaspar made in 2008, the only parameters which won't be renegotiated are SSLCACertificateFile/Path and SSLCADNRequestFile/Path. This is because of the lacking OpenSSL's SSL_set_cert_store() function, which always seem to be the case with the latest versions (AFAICT). OpenSSL 1.0.2 and later will address this. It supports separate verification and chain building stores which can be set at the SSL_CTX or SSL level. See: http://www.openssl.org/docs/ssl/SSL_CTX_set1_verify_cert_store.html Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: svn commit: r1546693 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_init.c
On 01/12/2013 11:16, Kaspar Brand wrote: On 30.11.2013 12:54, Graham Leggett wrote: A question out of ignorance on my side. Will/can the above directive be able to influence / somehow affect the ENGINE_ctrl_cmd_string() openssl call needed when using dynamic engines in openssl (the engine -pre and -post options specifically)? Steve is probably the best person to answer this, but in my view, SSLOpenSSLConfCmd is meant to expose the SSL_CONF API, and should not be used to mix in ENGINE API things, too. Well at present there is no ENGINE interface for SSL_CONF. As pointed out it isn't a good fit for general ENGINE configuration but it could be updated in future to support ENGINE based private keys. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: svn commit: r1546693 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_init.c
On 30/11/2013 11:54, Graham Leggett wrote: I've picked the pkcs11 support apart in openssl to discover that there are really two engines at work, the dynamic engine capable of loading engines from dynamic libraries, and then the pkcs11 engine which is just an implementation that happens to be (if you use opensc anyway) loadable as a dynamic library (this will be obvious to an openssl developer but wasn't obvious to me from the documentation I've read to date, which doesn't make clear that two engines are at work, or where the one engine begins and the other ends). Well normally the dynamic ENGINE doesn't matter because it is handled transparently behind the scenes. If you lookup an ENGINE called pkcs11 it will first look in its internal table. If that fails it attempts to use the dynamic ENGINE to load an ENGINE from an appropriate directory with an appropriate name. The precise location depends on how OpenSSL is configured but it might for example try to load /usr/local/ssl/engines/libpkcs11.so. If that fails you get an error. It's only if you want to load an ENGINE manually that you have to worry about the dynamic ENGINE. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: mod_ssl and pkcs11
On 27/11/2013 12:26, Nick Gearls wrote: Maybe it's time to remove all redundant code in mod_ssl and use all features of OpenSSL; PKCS#11 will then be automatically supported and the maintenance of mod_ssl will be simplified a lot. PKCS#11 support isn't native in OpenSSL though some third party ENGINEs do include partial support. Completely transparent support is tricky (and in some cases impossible) due several factors including the way PKCS#11 handles fork(). Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On 17/11/2013 15:25, Dr Stephen Henson wrote: Evil hack workaround: create a temporary SSL structure from the SSL_CTX of interest after you call SSL_CTX_get_certificate, call SSL_get_certificate on it and then free up the temp SSL structure. That *should* work on all the versions of OpenSSL of interest. That's not very efficient and makes me cringe a bit but you'd only go through it once on start up. Erk typo.. I of course meant ...after you call SSL_CTX_use_certificate_file or SSL_CTX_use_certificate_chain_file... A point to note about SSL_CTX_use_certificate_chain_file, at least in its current form. If the certificate file contains additional certificates this will end up adding them to the SSL_CTX using SSL_CTX_add_extra_chain_cert. That is more efficient as it doesn't have to try and build the chain on each call. Unfortunately due to a limitation in OpenSSL 1.0.1 and earlier you can only have one chain for the SSL_CTX shared by all certificate types and all SSL structures created from it. That means if you have more than one certificate configured and they have different chains the second will replace the first in the SSL_CTX and it will end up sending the wrong chain in some cases. For OpenSSL 1.0.2 this limitation is removed and you can have different chains for each certificate type (and for SSL structures too) and it just uses the right one. This uses the function SSL_CTX_add1_chain_cert which adds a certificate to the chain for the current certificate. I *could* change SSL_CTX_use_certificate_chain_file to use SSL_CTX_add1_chain_cert instead of SSL_CTX_add_extra_chain_cert or perhaps have a different function. I'm always cautious about changing the behaviour of existing functions though as the most innocent change will usually break *something*, though I can't see how it can in this case. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl? (was: Re: [PATCH 55593] Add SSLServerInfoFile directive)
On 13/11/2013 14:06, Kaspar Brand wrote: I'm not proposing to drop support for encrypted private keys from 2.4.x (yet), to be clear - I guess we need to keep this for quite some while for backwards compatibility. I suggest, however, to only support unencrypted private keys with the SSLOpenSSLConfCmd PrivateKey directive (in trunk and when backported to 2.4.x), and possibly remove support for encrypted private keys for SSLCertificate[Key]File in trunk. I.e., I'd be interested in hearing whether people are in favor of (or opposition to): - only supporting unencrypted private keys with SSLOpenSSLConfCmd PrivateKey ... Just to clarify that. Do you mean that SSLOpenSSLConfCmd shouldn't work with encrypted private keys at all (e.g. return an error) or that it is just documented that they might not work as expected? The SSL_CONF code (which SSLOpenSSLConfCmd uses) should have support for encrypted private keys as other applications might want to use it. The SSL_CONF code wasn't designed exclusively for mod_ssl use: though I have to admit I was partly thinking about how useful it could be in mod_ssl when I wrote it. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On 17/11/2013 15:01, Kaspar Brand wrote: One issue I'm facing with the current implementation is that when relying on SSL_CTX_use_certificate_file/ SSL_CTX_use_certificate_chain_file to configure the cert, there's no way to get at the X509 * which really got configured for the SSL_CTX (remember that we're compiling with OPENSSL_NO_SSL_INTERN for OpenSSL 1.0.0 or later). I don't think it helps if you don't use OPENSSL_NO_SSL_INTERN either. The actual certificate configured is in a CERT structure (which can be part of SSL_CTX or SSL structures) which is defined in a private header file. Steve, could you consider adding SSL_CTX_get_certificate, which would allow retrieving the current cert (i.e. one set by the last SSL_CTX_use_certificate* call)? And perhaps SSL_CTX_get_privatekey as its companion, at the same time? Without SSL_CTX_get_certificate at least, we can't call ssl_stapling_init_cert, unfortunately. I can certainly add functions to OpenSSL 1.0.2 and later, I'd regard it as a useful addition. It's problematical adding it to earlier releases as we have a no new functionality policy for bug fix releases. Evil hack workaround: create a temporary SSL structure from the SSL_CTX of interest after you call SSL_CTX_get_certificate, call SSL_get_certificate on it and then free up the temp SSL structure. That *should* work on all the versions of OpenSSL of interest. That's not very efficient and makes me cringe a bit but you'd only go through it once on start up. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl? (was: Re: [PATCH 55593] Add SSLServerInfoFile directive)
On 13/11/2013 14:06, Kaspar Brand wrote: Taking a step back, however, I wonder what problem we're really solving with the support for encrypted private keys. SSLPassPhraseDialog and its three incarnations (builtin, pipe and exec) have been in mod_ssl ever since 2.0, sure, but what do they actually protect against? Are private keys for mod_ssl really still typically encrypted, as the comment in ssl_engine_pphrase.c written in 1998 is telling us? I can vaguely recall that some of that code is designed to avoid the need to enter the private key passphrase more than once by decrypting private keys once and storing the unencrypted forms in serialised form. Unfortunately it does this in an algorithm specific way which means the whole lot needs updating every time a new algorithm arrives. The strategy will also only work for file based keys. If in future you want to support a key in an HSM it may not be even possible to serialise it. The passphrase may also be outside software control (for example entered into the device via a pinpad). Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 23/10/2013 15:30, Kaspar Brand wrote: On 22.10.2013 22:04, Dr Stephen Henson wrote: Only bit I'm not completely sure about is the use of the SSL_CONF_CTX structure in modssl_ctx_t. It's done that way to avoid having to keep creating and destroying the SSL_CONF_CTX for each directive but a quick test showed it was creating several other SSL_CONF_CTX structures which were never used. Right now, the SSL_CONF_CTX_* handling is in ssl_init_ctx_protocol, which is called once for each vhost (and each vhost has its own modssl_ctx_t), so the change you applied with r1534754 doesn't really change much as far as the SSL_CONF_CTX structure handling is concerned, I think. To prevent unnecessary SSL_CONF_CTX structures from being created, it should be sufficient to enclose that block with an if (mctx-ssl_ctx_param-nelts 0) condition, IINM. Well the handling remains in ssl_init_ctx_protocol but now an SSL_CONF_CTX with appropriate flags is created in moddssl_ctx_init. That is done because a valid SSL_CONF_CTX is needed to call SSL_CONF_cmd_value_type in ssl_cmd_SSLOpenSSLConfCmd. So my thought was (if unnecessary SSL_CONF_CTX creation is a problem) change the modssl_ctx_init to just set mctx-ssl_ctx_config to NULL and instead create a new SSL_CONF_CTX in ssl_cmd_SSLOpenSSLConfCmd if mctx-ssl_ctx_config is NULL. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 22/10/2013 20:14, Trevor Perrin wrote: On Mon, Oct 21, 2013 at 5:45 AM, Dr Stephen Henson shen...@opensslfoundation.com wrote: On 21/10/2013 05:09, Trevor Perrin wrote: BTW I've just added some experimental code to the OpenSSL master branch. It adds key/certificate support to SSL_CONF and a new function SSL_CONF_cmd_value_type. The Apache side isn't added yet but should be pretty straight forward. Cool, if you do the Apache side I'll try to follow your footsteps and extend ServerInfo to work with SSL_CONF (in OpenSSL and Apache). http://svn.apache.org/r1534754 This needs the OpenSSL master branch. It doesn't (yet) work with 1.0.2-stable but I'll be backporting the functionality in the near future. I tested it against a new DH parameters directive and it seemed to work OK. Only bit I'm not completely sure about is the use of the SSL_CONF_CTX structure in modssl_ctx_t. It's done that way to avoid having to keep creating and destroying the SSL_CONF_CTX for each directive but a quick test showed it was creating several other SSL_CONF_CTX structures which were never used. Maybe there's a better way to handle that or just create the SSL_CONF_CTX on first use? Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 21/10/2013 05:09, Trevor Perrin wrote: Seems like a lot of work. For example, how would the generic SSLConfCmd commands get hooked-up with passphrase handling for the key files? BTW I've just added some experimental code to the OpenSSL master branch. It adds key/certificate support to SSL_CONF and a new function SSL_CONF_cmd_value_type. The Apache side isn't added yet but should be pretty straight forward. Even with the existing Apache certificate code it should be possible to handle a per-certificate server info directive. You'd just set the certificate again if you had more than one. For example: ... SSLOpenSSLConfCmd Certificate cert1.pem SSLOpenSSLConfCmd ServerInfoFile info1.pem SSLOpenSSLConfCmd Certificate cert2.pem SSLOpenSSLConfCmd ServerInfoFile info2.pem ... The point is that it will reload the certificate (which has been set before by the existing Apache certificate directives) and set it as the current certificate, which any subsequent options will use. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 02/10/2013 08:35, Kaspar Brand wrote: An overhaul of ssl_engine_pphrase.c:ssl_pphrase_Handle() - and its use of the tVHostKeys and tPublicCert hashes - would probably be welcomed by quite a few devs, though (see e.g. https://svn.apache.org/r1069765). Hmm.. I had a look at ssl_pphrase_Handle and agree with the comment ;-) I'm considering how it might be revised with minimal chance of breakage while permitting arbitrary numbers of certificates and keys. At present the serialised versions of each key and certificate is indexed using vhost:alg. How about instead having a single one indexed as vhost? This could contain all keys and certificates in a single buffer. Keys would be stored in PKCS#8 format to avoid algorithm dependencies. The auto increment feature of the i2d/d2i functions is especially designed to support this. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 11/10/2013 05:14, Kaspar Brand wrote: On 09.10.2013 15:52, Dr Stephen Henson wrote: It's tempting to just add a directive but after some thought I think expanding Apache SSL_CONF handling is the way to go. This would add some future proofing so we don't have to go through this all again in future. Yes, please. Let's not perpetuate the pattern of adding another directive to mod_ssl whenever a new OpenSSL feature needs to be exposed. As an interim step, and sort of a proof of concept, it might be worthwile to see if adding equivalents of SSLCertificateFile and SSLCertificateKeyFile to SSLOpenSSLConfCmd (in ssl/ssl_conf.c, at the OpenSSL end) would allow support for per-cert options. The concept of collecting the options in ssl_cmd_SSLOpenSSLConfCmd and replying them at the appropriate place in ssl_engine_init.c would remain, and you would use something like VirtualHost ... OpenSSLConfCmd KeyFile foo.key OpenSSLConfCmd CertificateFile foo.crt OpenSSLConfCmd ServerInfoFile foo.pem OpenSSLConfCmd KeyFile bar.key OpenSSLConfCmd CertificateFile bar.crt OpenSSLConfCmd ServerInfoFile bar.pem /VirtualHost to configure multiple cert and current-cert settings in turn (and not worry about the case of encrypted private keys, for the time being). KeyFile would result in calling SSL_CTX_use_PrivateKey_file(), and CertificateFile in SSL_CTX_use_certificate_chain_file(). I had considered some equivalents of CertificateFile for the SSL_CONF API and definitely intend that for a future version of SSL_CONF. The idea of being able to have OpenSSL handle the often complex issue of certificate and key configuration properly and releave the burden from applications is rather compelling. However I felt it needed rather more thought as it's a complex issue. I'd like to handle all sorts of things like HSM keys, PKCS#12 files etc etc. I also have to mention that I wasn't at all sure this would work with Apache's rather curious configuration needs. As an experimental feature to test the current-cert handling it would be easy enough though. [BTW: also on the list for SSL_CONF is certificate verification: but that's considerably harder] 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. ssl_engine_init.c:ssl_init_server_ctx() is most likely the appropriate place for inserting this (i.e., it's perhaps best to move the current SSL_CONF_CMD block from the end of ssl_init_ctx_protocol() to somewhere in ssl_init_server_ctx(), maybe some tweaks are needed for ssl_init_server_certs(), too). What I would try to avoid right now is fiddling with the tPublicCert, tVHostKey and tPrivateKey hashes (and the ssl_asn1_table_* friends). Well moving the SSL_CONF_CMD block does have some consequences. I placed it at (what I think is) the last possible point for a reason: so the SSL_CONF could reset just about anything set by Apache. I think at least some twiddling with ssl_pphrase_Handle() would be needed because Apache will (I think) choke if you have no certificates configured. It might be an idea to support certificateless servers anyway as someone might want one with anon-DH or PSK.. though I don't think PSK is currently supported: yes even as I typed that I wondered if that could be fixed through SSL_CONF. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 10/10/2013 23:18, Trevor Perrin wrote: How would you expect the code to track the Cert - ServerInfo relationship between these points? Disclaimer: it's been a while since I looked at that code and someone else might have a better idea. It didn't quite work in the way I recalled. It may be a bit messy to handle, to say the least. AFAICS the certificate and key files both go through the function ssl_cmd_check_aidx_max and store the filenames with an associated index. At that point you could save the last index used and store any associated ServerInfo with the same index. I *think* you then have to delve into ssl_pphrase_Handle() [note the comment on the way in] and somehow link the ServerInfo index with something you can use to recognise it later. The algorithm type 'at' might be usable or perhaps turn the algorithm type into one of the SSL_AIDX_ALGORITHM values? After that you look for an appropriate ServerInfo value when SSL_use_certificate or SSL_use_PrivateKey is called (you'll be able to use the associated SSL_AIDX_ALGORITHM value) and set the ServerInfo. There *should* be an easier way to do it than this but I can't immediately see what it is. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 09/10/2013 02:22, Trevor Perrin wrote: Hi Kaspar, Stephen, So I think where things stand is that the OpenSSL 1.0.2 branch is capable of handling ServerInfo on a per-algorithm basis, but it's not clear how to expose this through Apache. (My previous email was naive, I was thinking maybe Stephen was saying the current certificate / current key concept was already exposed through to Apache, but I don't think it is). Technically the current certificate concept doesn't need exposing at all. You just have to make sure you set all the relevant parameters *after* you set the certificate they apply to and *before* you set another one. So is there some way I could implement mod_ssl support for ServerInfo without a major rewrite of how mod_ssl handles certs and keys? (which some of the previous suggestions seemed to entail...) I can see two ways to do this. One is to add some code to Apache that just covers ServerInfo and is a directive at the same level as certificates (apologies, not sure what the actual term for that is). You then make sure you apply the value of that directive when you set the relevant certificate. The other is to enhance the SSL_CONF code in Apache so it can also store per-certificate parameters. The SSL_CONF currently works in Apache is to store all the SSL_CONF commands in an array during configuration and replay them when the SSL_CTX is set. That's OK for parameters that apply to the whole server (which reminds me support for client mode in Apache would be good too) but not for individual certificates. What you'd do to extend this is to have an array stored at the certificate level and replay it after the appropriate certificate is set. It's tempting to just add a directive but after some thought I think expanding Apache SSL_CONF handling is the way to go. This would add some future proofing so we don't have to go through this all again in future. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 02/10/2013 08:35, Kaspar Brand wrote: On 01.10.2013 12:15, Dr Stephen Henson wrote: That's just OpenSSL internals though. To handle ServerInfo properly in mod_ssl IMHO you would need a new directive as there's no support for per-certificate SSL_CONF commands: it wasn't intended to be used like that in its current form. This also runs against what IMHO is a long standing historical problem with the way mod_ssl handles certificates: it hard codes the algorithms used in the source. That means every new algorithm needs mod_ssl code changes to support: ECC for example. True. I guess it's a side effect of keeping private key pass phrases in the global SSLModConfigRec. From ssl_private.h: /* BIG FAT WARNING: SSLModConfigRec has unusual memory lifetime: it is * allocated out of the process pool and only a single such * structure is created and used for the lifetime of the process. [...] * This odd lifetime strategy is used so that encrypted private keys * can be decrypted once at startup and continue to be used across * subsequent server reloads where the interactive password prompt is * not possible. [...] * This should really be fixed using a smaller structure which only * stores that which is absolutely necessary (the private keys, maybe * the random seed), and have that structure be strictly ABI-versioned * for safety. Whether the latter is doable without breaking backward config compatibility (in particular for the SSLCertificate*File directives) needs further examination, I guess. I'd be interested in seeing what can be done to address this. One problem I noticed in the past is that the serialisation of keys in Apache is not algorithm independent: you can get around that by using PKCS#8 which is supported in all the versions of OpenSSL of interest. Well it works for software keys. For HSM keys there are some rather thorny issues which are trickier to handle. I don't think those are currently supported? Are you (or is anyone else) aware of any limitations on the OpenSSL side that prevent revision of the code to support arbitrary numbers of certificates in an algorithm independent way? There's one (relatively minor) one I can think of. If you set another certificate of the same type OpenSSL silently overwrites the old one. That means you can't currently catch configuration errors: e.g. trying to use two certificates of the same type. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 01/10/2013 05:53, Trevor Perrin wrote: On Sun, Sep 29, 2013 at 1:06 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: On 28.09.2013 18:34, Dr Stephen Henson wrote: How about something like: int SSL_CONF_cmd_type(SSL_CONF_CTX *cctx, const char *cmd); which can return things like... SSL_CONF_TYPE_INVALID:unrecognised name. SSL_CONF_TYPE_FILE: file name. SSL_CONF_TYPE_DIR:directory name. ... others ... SSL_CONF_TYPE_STR:string with no special meaning. Sounds good, yes. Sounds fine to me. But another wrinkle is occurring to me: We're going to need different ServerInfo files for different certs (since things like Certificate Transparency and TACK will return different data depending on the server's cert/key). The OpenSSL code was written on the assumption of one ServerInfo file per SSL_CTX, so will need a bit of rework. But it's worth discussing what the API should be. There are currently 8 possible key/cert types in OpenSSL (ssl/ssl_locl.h): #define SSL_PKEY_RSA_ENC 0 #define SSL_PKEY_RSA_SIGN 1 #define SSL_PKEY_DSA_SIGN 2 #define SSL_PKEY_DH_RSA 3 #define SSL_PKEY_DH_DSA 4 #define SSL_PKEY_ECC5 #define SSL_PKEY_GOST94 6 #define SSL_PKEY_GOST01 7 I think we'd rather not try to embed OIDs or whatever in the ServerInfo files. Perhaps the ServerInfoFile ConfCmd could be annotated to refer to these identifiers somehow? SSLOpenSSLConfCmd ServerInfoFile_RSA_ENC certs/ServerInfo1.pem SSLOpenSSLConfCmd ServerInfoFile_RSA_SIGN certs/ServerInfo2.pem - or - SSLOpenSSLConfCmd ServerInfoFile 0 certs/ServerInfo1.pem SSLOpenSSLConfCmd ServerInfoFile 1 certs/ServerInfo2.pem Any thoughts?? I'd rather we didn't do that for reasons I'll expand on below. OpenSSL has the concept of the current certificate. That is the last certificate set. So you set certificate foo and then any parameters you set are associated with it until another certificate is set. For OpenSSL 1.0.2 you can set custom chains for each certificate type for example. You couldn't do that before 1.0.2. So ServerInfo would really need an option to set at the SSL_CTX or the SSL level in OpenSSL as you can set different certificates for each SSL structure. It would use the current certificate at the SSL_CTX or SSL level to decide which is affected. That's just OpenSSL internals though. To handle ServerInfo properly in mod_ssl IMHO you would need a new directive as there's no support for per-certificate SSL_CONF commands: it wasn't intended to be used like that in its current form. This also runs against what IMHO is a long standing historical problem with the way mod_ssl handles certificates: it hard codes the algorithms used in the source. That means every new algorithm needs mod_ssl code changes to support: ECC for example. Ideally it should be able to send an arbitrary number of certificates and keys to OpenSSL and let it decide what to do with them. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 01/10/2013 11:15, Dr Stephen Henson wrote: To handle ServerInfo properly in mod_ssl IMHO you would need a new directive as there's no support for per-certificate SSL_CONF commands: it wasn't intended to be used like that in its current form. Though thinking about this some more there *could* be a way to handle per-certificate options for SSL_CONF. At the moment we have some flags setting the context of the commands: currently server or client. We could have an additional one to mean the command is a per-certificate command instead of per-SSL or per-SSL_CTX. That would need more work on the mod_ssl side to add the equivalent commands for each certificate and call them at the appropriate time. Though for just one per-certificate option it would be easier to just have a new directive. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 28/09/2013 14:42, Kaspar Brand wrote: If the ability to specify relative path names with SSLOpenSSLConfCmd is considered an absolutely essential feature, then OpenSSL could perhaps standardize its option names somewhat - e.g. by always naming those which take a file name argument with ...File. We could then handle such a case in mod_ssl as illustrated by the attached patch. An alternative would be to specify a callback to OpenSSL which can be used to transform a filename which is called whenever any option name requires a file. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 28/09/2013 14:56, Dr Stephen Henson wrote: On 28/09/2013 14:42, Kaspar Brand wrote: If the ability to specify relative path names with SSLOpenSSLConfCmd is considered an absolutely essential feature, then OpenSSL could perhaps standardize its option names somewhat - e.g. by always naming those which take a file name argument with ...File. We could then handle such a case in mod_ssl as illustrated by the attached patch. An alternative would be to specify a callback to OpenSSL which can be used to transform a filename which is called whenever any option name requires a file. On second thoughts that could prove messy and might involve processing the same command more than once. How about something like: int SSL_CONF_cmd_type(SSL_CONF_CTX *cctx, const char *cmd); which can return things like... SSL_CONF_TYPE_INVALID: unrecognised name. SSL_CONF_TYPE_FILE: file name. SSL_CONF_TYPE_DIR: directory name. ... others ... SSL_CONF_TYPE_STR: string with no special meaning. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 25/09/2013 06:39, Kaspar Brand wrote:
On 25.09.2013 04:13, Trevor Perrin wrote:
The feature is checked in to the 1.0.2 branch [1], so we'd like to
expose it through Apache.
The patch is pretty simple. I suppose more tests or docs might be
needed (?), which I'm happy to write.
Anyways, is this something Apache is interested it? Does the patch
look correct? [2]
I'd very much prefer to see this supported via SSLOpenSSLConfCmd
(http://svn.apache.org/r1421323), and not code this into mod_ssl by
adding yet another directive. For the authz_file / RFC 5878 stuff, I did
some experiments at the time, and am attaching a[n untested] patch for
SSL_CTX_use_serverinfo_file - could you give it a try?
Depending on when exactly you need the SSL_CTX_use_serverinfo_file to
happen in ssl_engine_init.c, we might have to move around the #ifdef
HAVE_SSL_CONF_CMD block somewhat, but this shouldn't be a real issue
(for authz_file, it was necessary/doable).
Couple of minor refinements. If you do:
+ {cmd_serverinfo_file, ServerInfoFile, serverinfo},
It gets supported in command line utilities to (like s_server, making it
unnecessesary to code it separately). Also if it is only used for servers you
need something like:
if (!(cctx-flags SSL_CONF_FLAG_SERVER))
return -2;
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
Re: Diffie-Hellman group parameters 1024 bit and Perfect Forward Secrecy
On 28/06/2013 10:31, Rob Stradling wrote: How about making ECDH parameters configurable from within Apache too? The current technique of hard coding the ECDH parameters isn't correct but it's the best release versions of OpenSSL can do. The unreleased OpenSSL 1.0.2 can be configured to use the client's supported curve list extension to automatically use the highest preference curve. Optionally server curve preferences can be set too. OpenSSL 1.0.2 also includes some generalised configuration code which means any application which uses the SSL configuration API (there is provisional code for this in 2.5-dev) can be configured using the SSLOpenSSLConfCmd directive. ECDH curves (and many other things) can be set this way. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: svn commit: r1374640 - /httpd/httpd/branches/2.2.x/STATUS
On 19/08/2012 18:22, Kaspar Brand wrote: On 18.8.12 21:51, William A. Rowe Jr. wrote: to drop the #ifndef around SSL_PROTOCOL_SSLV2 in ssl_private.h, this should also make some of the other #if[n]def OPENSSL_NO_SSL2 encapsulations unnecessary. + [wrowe] agreed the patch was wrong, the #ifdef needed to be moved + up four lines. Behavior is now correct in patch .2 + Disagree about retaining SSL_PROTOCOL_SSLV2; this is one + of the most basic design patterns which exists to ensure + that we don't have some lingering code which is still + attempting to pursue SSLV2 games, not to mention that + the various macros and functions in those blocks may + simply disappear disappear in an OPENSSL_NO_SSL2 build. + Bad idea, it helps us catch current and future problems. After a closer look at the mechanics of OPENSSL_NO_SSL2 in OpenSSL, I think there's a misunderstanding of how OpenSSL exposes this compile-time option to applications linking against libssl. OpenSSL itself only defines OPENSSL_NO_SSL2 in the following case (openssl/ssl.h): #if (defined(OPENSSL_NO_RSA) || defined(OPENSSL_NO_MD5)) !defined(OPENSSL_NO_SSL2) #define OPENSSL_NO_SSL2 #endif (ssl.h is not customized by OpenSSL's Configure script, AFAICT you would have to call openssl version -f and look for any flags set at compile time.) I.e., unless mod_ssl is explicitly compiled with -DOPENSSL_NO_SSL2 (set through CPPFLAGS/CFLAGS), an #ifdef OPENSSL_NO_SSL2 has no effect, and the blocks enclosed with #ifndef OPENSSL_NO_SSL2 will get included, irrespective of how OpenSSL has been compiled. The usual way is to use no-ssl2 as an argument to Configure or config which then adds OPENSSL_NO_SSL2 into crypto/opensslconf.h Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: svn commit: r1374214 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c
On 18/08/2012 08:00, Kaspar Brand wrote: On 17.8.12 13:59, jor...@apache.org wrote: Author: jorton Date: Fri Aug 17 11:59:45 2012 New Revision: 1374214 URL: http://svn.apache.org/viewvc?rev=1374214view=rev Log: * modules/ssl/ssl_engine_init.c (ssl_init_proxy_certs): Fix test for missing decrypted private keys, and ensure that the keypair matches. [...] @@ -1412,6 +1421,8 @@ static void ssl_init_proxy_certs(server_ ssl_die(s); } +/* ### Why is all the following done? Why is it necessary or + * useful for the server to try to verify its own client cert? */ It's the somewhat surprising way to let OpenSSL build the chain of the client cert, cf. http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3c4e620c5e.3050...@opensslfoundation.com%3E http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3c4e61c3ce.4020...@velox.ch%3E http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3c4e625521.3000...@opensslfoundation.com%3E Though this quirk has been addressed in the current development version of OpenSSL. It's now possible to set certificate chains on a per-type and per-SSL context basis, instead of one per parent SSL_CTX. The functionality is likely to be back ported to OpenSSL 1.0.2. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Moving on
On 20/04/2012 12:25, Igor Galić wrote: Hi folks, I started cleaning out mod_ssl and mod_rewrite's comments in order for them to be accessible to mere mortals. Similarly as we have started doing with their respective documentation. The patches can be found here: http://sprunge.us/VCZB http://sprunge.us/gbNj I will commit them unless someone objects that these sort of comments have more value beyond the purely sentimental. Personally I like humorous or thought provoking comments in source files it shows the human side of the authors. If we want to make the whole thing bland and faceless then so be it. I think it will be lessened as a result. If that's sentimental then I suppose I am. I'd like to hear other peoples opinions on this. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Moving on
On 20/04/2012 14:58, Tom Evans wrote: On Fri, Apr 20, 2012 at 2:46 PM, Rich Bowen rbo...@rcbowen.com wrote: … and Where's the spoons? Where's the spoons? Where's the bloody spoons? But with no mention of swimming pools full of puppies or Lord Palmerston? Of course no one gets it... I was either that, bicycles or asking if someone had passed their driving test. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
CVE-2012-2110 and mod_ssl.
Guys, A note about the impact of the potentially exploitable OpenSSL vulnerability CVE-2012-2110 on mod_ssl. The OCSP part of Apache 2.4 mod_ssl makes use of the d2i_OCSP_RESPONSE_bio call which is affected. Since OCSP data relies on DNS it cannot be trusted and an attacker could inject malicious data by this route if OCSP or OCSP stapling is enabled. An alternative technique which would not rely on the OpenSSL upstream fix would be to use d2i_OCSP_RESPONSE instead. The mod_ssl code also makes use of the affected d2i_X509_bio and d2i_PrivateKey_bio calls but these load certificates and keys for server configuration and so the data should come from trusted sources. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: invalid free in ssl
On 26/02/2012 22:30, Stefan Fritsch wrote:
Hi,
running ab via https on httpd trunk with mpm event, I got some crashes
with
*** glibc detected *** /usr/local/apache2/bin/httpd: free(): invalid
pointer: 0x0883bd68 ***
or
*** glibc detected *** /usr/local/apache2/bin/httpd: double free or
corruption (fasttop): 0xe1614d58 ***
The free happens inside openssl in EC_GROUP_free(). Does anyone have
any idea how to debug this? Steve? I still have the coredump and could
dump interesting values.
Hmmm... it looks like there is a race condition in here:
EC_KEY *ssl_callback_TmpECDH(SSL *ssl, int export, int keylen)
{
conn_rec *c = (conn_rec *)SSL_get_app_data(ssl);
static EC_KEY *ecdh = NULL;
static int init = 0;
/* XXX Uses 256-bit key for now. TODO: support other sizes. */
ap_log_cerror(APLOG_MARK, APLOG_TRACE2, 0, c,
handing out temporary 256 bit ECC key);
if (init == 0) {
ecdh = EC_KEY_new();
if (ecdh != NULL) {
/* ecdh-group = EC_GROUP_new_by_nid(NID_secp160r2); */
EC_KEY_set_group(ecdh,
EC_GROUP_new_by_curve_name(NID_X9_62_prime256v1));
}
init = 1;
}
return ecdh;
}
Consider two threads calling that at once with init == 0. The static variable
ecdh could end up being modified by two threads simultaneously.
You could include a lock in there or just call ssl_callback_tmpECDH before
starting any threads. Alternatively if you're just setting one curve then you
might as well call SSL_CTX_set_tmp_ecdh and avoid the callback altogether.
[BTW the whole ECDH parameter passing technique is a bit broken in OpenSSL and
needs revising]
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
Re: Certificate handling limitations in mod_ssl.
On 05/02/2012 11:08, Kaspar Brand wrote: On 04.02.2012 15:27, Dr Stephen Henson wrote: IMHO to avoid these problems it would be better if mod_ssl could send an arbitrary number of certificates and keys to OpenSSL and leave it to OpenSSL to process them in an appropriate manner. Would that mean supplying names of key/certificate files to OpenSSL, or are you thinking of sending parsed keys/certs (like SSL_CTX_use_PrivateKey() etc. does right now)? The existing API would still work so you'd just be able to use SSL_CTX_use_PrivateKey and SSL_use_PrivateKey etc as now but it could be used more times. Dealing with encrypted keys might become more tricky, depending on how the API for this would look like (currently, mod_ssl remembers the unencrypted keys in a separate table, so that they can survive a reload). I had a quick look at that a while ago. It seems to be rather old code using algorithm specific key serialisation functions. It has been possible to serialise arbitrary private keys using the PKCS#8 format for some years now. Also support for ENGINE based private keys is something mod_ssl should support but it is problematical. A key might reside on an HSM ENGINE through an API which OpenSSL has restricted control over including authentication (e.g. a PIN pad, card insertion etc). In some cases you cannot reload the EVP_PKEY structure without reauthentication. I'm not sure if that could be worked round by attempting to cache the EVP_PKEY structure instead. If finer control over some operations (for example to detect configuration errors) is required OpenSSL could be extended to support that. This would certainly help. Things which come to mind: host name mismatch (i.e., cert does not include DNS name for ServerName/ServerAlias), private-vs.-public-key mismatch, missing chain. I'm currently working on enhancing the API. In OpenSSL HEAD it is now possible to use different certificate chains per key type tied to an SSL or SSL_CTX structure: overcoming the limitation of only allowing one custom chain per SSL_CTX. Building and caching of chains with error detection is something I'll also include. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: OpenSSL configuration and mod_ssl
On 04/02/2012 07:32, Kaspar Brand wrote: On 02.02.2012 15:13, Dr Stephen Henson wrote: int SSL_CTX_config(SSL_CTX *ctx, const char *config_name); Where config_name is a named configuration option in the OpenSSL configuration file. This has the substantial advantage that there would then be one configuration file format used by all OpenSSL applications. The disadvantage is that it would look nothing like the existing Apache configuration format. Maybe mod_ssl could offer both - a directive for configuring via key-value pairs for simple cases, and a config file based way for complex setups. (In some way, it's what PHP currently does with the php_value/php_admin_value directives and php.ini.) I agree some of the more complex operations might need nested configuration options (for example setting verification policies). It should be possible to setup most options for an SSL_CTX or SSL structure this way, including which key(s) and certificate(s) to use, though not sure mod_ssl would make use of that. BTW: I would like to see SSL_set_config_string(), too - for those mod_ssl options which can be set on a per-directory basis. Yes I certainly plan to have an equivalent for SSL structures too. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Certificate handling limitations in mod_ssl.
The way mod_ssl currently handles certificates and private keys is rather restrictive and means some of OpenSSL's current and planned future features can't be used automatically. Currently mod_ssl hard codes algorithms and has a limitation of one certificate per algorithm. This has two consequences... 1. New algorithms (such as GOST and fixed DH) cannot be configured and need to be added into the mod_ssl code. 2. Support for multiple certificates for a given algorithm is not supported. For example future full use of ECC ciphersuites might have different certificates for different curves the selection of which is determined by the curves the client supports. IMHO to avoid these problems it would be better if mod_ssl could send an arbitrary number of certificates and keys to OpenSSL and leave it to OpenSSL to process them in an appropriate manner. If finer control over some operations (for example to detect configuration errors) is required OpenSSL could be extended to support that. Thoughts? Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Segfault in openssl's err_cmp when using SSLCryptoDevice and new SSLProxyMachineCertificateChainFile
On 03/02/2012 17:45, Daniel Ruggeri wrote: On 2/2/2012 1:02 PM, Daniel Ruggeri wrote: Since this happens with every attempt to start, I suspect it has nothing to do with the new directive and more to do with something I did on the openssl build. I was, indeed, doing something stupid. A build with openssl 1.0.0g replicates the behavior of 0.9.8g in that it fails when SSLProxyMachineCertificateChainFile is enabled. The annoying part is that (due to the error I get when running in dbx) I can get no useful information in a debug session from Solaris. ... so I've switched to RHEL and gdb and have interesting information. Under Linux, I get this error on init: [Fri Feb 03 10:56:21 2012] [error] Init: Failed to enable Crypto Device API `chil' [Fri Feb 03 10:56:21 2012] [error] SSL Library Error: 2164682852 error:81067064:CHIL engine:HWCRHK_INIT:already loaded [Fri Feb 03 10:56:21 2012] [error] SSL Library Error: 638287981 error:260B806D:engine routines:ENGINE_TABLE_REGISTER:init failed This only happens when SSLProxyMachineCertificateChainFile is set With some quick debugging I see that the hwcrhk_finish DOES NOT get called during ssl_cleanup_pre_config... but DOES get called when the directive has been removed. To me, it looks like httpd has not registered the engine for cleanup, but that certainly shouldn't be impacted by this patch. It seems something in the process of loading the store is complicating things. I'll continue poking around, but pointers are certainly appreciated. Hmm... the ENGINE code is careful not to shutdown an ENGINE if keys exist which make use of it. So there is a possibility that the some chain verification leaves a reference to an RSA key which prevents the ENGINE from closing down completely. In engines/e_chil.c try commenting out the line containing ERR_load_HWCRHK_strings(). Only side effect of doing that is you will only get numerical error codes and not error strings. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
OpenSSL configuration and mod_ssl
Guys, It has been apparent for some time that mod_ssl (and other applications) require a considerable effort to support new features in OpenSSL. A simple example is when a new flag is added which some, but not all, users may want to set. Once this flag appears in an OpenSSL release every OpenSSL based application needs to be modified to support and document it. Specification of this option might be via a command line option or (in the case of mod_ssl and others) a configuration file. It would IMHO be far better if a mechanism existed to support automatic configuration of some options by conforming applications. There is a current example where this works well: the cipher string. With the inclusion of TLS v1.2 in the upcoming OpenSSL 1.0.1 release several new ciphersuites based on SHA256 and GCM have appeared. An application generally doesn't need to know or care what these are. A user can enable or disable them by just using the cipher string: it is passed as an opaque string which OpenSSL interprets. So my thoughts are that this concept could be generalised. A simple answer is to add new string setting options. For example: int SSL_CTX_set_options_string(SSL_CTX *ctx, const char *str); This works for existing simple configuration but a new string (for example TLS 1.2 supported signature algorithms) might be added in the future so then we're back to having to explicitly add support to all applications for each new string configuration option. So perhaps: int SSL_CTX_set_config_string(SSL_CTX *ctx, const char *name, const char *value); Where the values of name can expand over time. I'm not completely sure that this could be handled by the mod_ssl configuration routines, perhaps someone could comment on that? A third method is to delegate the configuration completely to OpenSSL using a separate configuration file. So, we'd have an option to set the configuration file to use and then something like: int SSL_CTX_config(SSL_CTX *ctx, const char *config_name); Where config_name is a named configuration option in the OpenSSL configuration file. This has the substantial advantage that there would then be one configuration file format used by all OpenSSL applications. The disadvantage is that it would look nothing like the existing Apache configuration format. Thoughts? Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: OpenSSL configuration and mod_ssl
On 02/02/2012 14:22, Plüm, Rüdiger, VF-Group wrote: It has been apparent for some time that mod_ssl (and other applications) require a considerable effort to support new features in OpenSSL. A third method is to delegate the configuration completely to OpenSSL using a separate configuration file. So, we'd have an option to set the configuration file to use and then something like: int SSL_CTX_config(SSL_CTX *ctx, const char *config_name); -0 from mod_ssl perspective. How do you configure which configuration file to use in this case? If it is the system wide one I don't regard this as beneficial as a web server operator might not have write access to it. Sorry should've explained that bit. The configuration file to use wouldn't be hard coded. There would be a separate API which would allow an application to decide which configuration file to use. It could be either a system wide one or a local one dealing with mod_ssl only. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Segfault in openssl's err_cmp when using SSLCryptoDevice and new SSLProxyMachineCertificateChainFile
On 30/01/2012 23:43, Daniel Ruggeri wrote: It's been hell lately - sorry for the sloow reply On 1/19/2012 1:13 AM, Sander Temme wrote: Interesting... which version of OpenSSL? Must be 0.9.7 or 0.9.8, because err_cmp() disappeared after that. And the signature doesn't match what we're seeing in the backtrace. And which platform? Solaris? SPARC or x86_64? I was building on Sparc - but I'll have to try with openssl 1.0.0. ... So the combination of directives causes some memory to be overwitten that ends up pointing outside httpd's allocated address space. Does the order of the directives matter? Which Engine if I may ask? A fix was applied to the CHIL Engine that removes a dangling cleanup function pointer which caused a segfault on startup on platforms that vary the address location in which libraries are loaded (RHEL 5 being a prime example). I don't remember off the top of my head which OpenSSL version got the fix. Can you reproduce with a non-optimized, debug/symbols enabled build of OpenSSL and Apache? With the latest versions of each? S. I'll try messing with the order and will let you know how I get on - the chil engine is the one in use but this is a fairly recent openssl (0.9.8r). I didn't explicitly enable optimization of either build but did explicitly add -g which seemed to create a build of httpd with debug symbols but a regular old build of openssl. I have some other platforms available (RHEL being one of them) and will try soon to see what I get there. The fix in 0.9.8r, the relevant patch is here: http://cvs.openssl.org/chngview?cn=19659 Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: mod_ssl and OPENSSL_NO_SSL_INTERN (Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?)
On 23/12/2011 07:52, Kaspar Brand wrote: On 22.12.2011 17:53, Dr Stephen Henson wrote: I've added a few new controls and one new function which should resolve this, see last few commits. I deleted a couple of functions duplicating functionality too. Let me know if you need further details or it needs fixing. Thanks for the very prompt reaction. With the attached changes to ssl.h, works fine for me. If you agree with these, my plan would be to commit the attached patch to trunk/2.4.x. Comments welcome. OK, thanks. I've fixed the two typos now. Your patch to trunk/2.4.x looks fine. You can simplify the clearing of the extra chain slightly by just unconditionally calling: SSL_CTX_clear_extra_chain_certs(ctx); which will just be a no op if the chain is empty. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: mod_ssl and OPENSSL_NO_SSL_INTERN (Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?)
On 22/12/2011 10:59, Kaspar Brand wrote: On 05.08.2011 07:41, Kaspar Brand wrote: On 03.08.2011 19:29, Dr Stephen Henson wrote: In OpenSSL 1.0.1 (unreleased) and later there is a feature to make all SSL related structures opaque and only allow them to be accessed through functions. This is enabled by setting OPENSSL_NO_SSL_INTERN before including any OpenSSL headers. Thanks for this information, this definitely seems a desirable goal for mod_ssl in the long term (pity it wasn't added to OpenSSL earlier). Ok, so now that OpenSSL 1.0.1 doesn't seem too far away, I had a closer look. With trunk/2.4.x, things are already in pretty good shape, I think. I haven't had time to try getting mod_ssl to work with this option. It is guaranteed to fail without some modification. There may well be some functionality missing in OpenSSL too. For mod_ssl, after some tweaking, two things are basically missing with the current 1.0.1 snapshots: 1) access to the SSL_CTX's extra_certs. Currently there's only SSL_CTX_add_extra_chain_cert(), but no way to get at the currently configured stack of certs, and no option to clear that stack. mod_ssl needs this for ssl_util_stapling.c:stapling_get_issuer(), ssl_engine_init.c:ssl_init_ctx_pkcs7_cert_chain(), and ssl_util_ssl.c:SSL_CTX_use_certificate_chain(). 2) access to the SSL_SESSION's compress_meth (read-only). Used in ssl_engine_vars.c:ssl_var_lookup_ssl_compress_meth(). Is there a chance to add these for the initial 1.0.1 release? I've added a few new controls and one new function which should resolve this, see last few commits. I deleted a couple of functions duplicating functionality too. Let me know if you need further details or it needs fixing. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: svn commit: r1160863 - in /httpd/httpd/trunk: docs/manual/mod/ modules/ssl/
On 17/09/2011 11:37, Kaspar Brand wrote: On 14.09.2011 22:32, Daniel Ruggeri wrote: My usage tests pass muster with the approach we have discussed, so I have updated trunk and the 2.2 backport proposal. At this point, I am satisfied with this particular patch, though I won't lose sight of the server-side issue. Since the patch should now be complete, I have given my vote in the 2.2 STATUS file and would appreciate any further review/votes. Looks good, judging from my (admittedly not very comprehensive) testing. +chain = X509_STORE_CTX_get1_chain(sctx); +sk_X509_shift(chain); +i=sk_X509_num(chain); pkp-ca_certs[n] = chain; I think with the sk_X509_shift(chain) line, we're leaking an X509 struct... maybe Steve can confirm (?). Adding a short comment as to why the first cert is dropped would be useful IMO, too. Yes you need store the returned value and free it with X509_free(). Note also that because you ignore return values of X509_verify_cert() you might have a situation where the chain is not complete and so deleting the last element will remove a non-root CA. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: svn commit: r1160863 - in /httpd/httpd/trunk: docs/manual/mod/ modules/ssl/
On 05/09/2011 17:32, Kaspar Brand wrote:
SSL_CTX_add_extra_chain_cert() isn't an option for us, I assume, so the
best we can probably do in ssl_init_proxy_certs()) is to load the certs
specified via ProxyMachineCertificateChainFile with
X509_STORE_load_locations and rely on OpenSSL's auto chain building
afterwards.
Potential gotcha is that you end up loading up client CAs in the trusted
certificate store which isn't always what you want. For example if that context
gets reused they'll be trusted server CA certificates later.
Also I think this:
+chain = sk_X509_new_null();
+for (i = 0; i sk_X509_num(sctx-chain); i++) {
+ sk_X509_push(chain, sk_X509_value(sctx-chain, i));
+}
along with:
+X509_STORE_CTX_free(sctx);
will end up freeing up the certificates you just added to the chain. You can
replace that all with:
chain = X509_STORE_CTX_get1_chain(sctx);
which creates a STACK_OF(X509) and ups the reference count of the added
certificates so they stick around after you free the context.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
Re: svn commit: r1160863 - in /httpd/httpd/trunk: docs/manual/mod/ modules/ssl/
On 23/08/2011 20:35, drugg...@apache.org wrote:
Author: druggeri
Date: Tue Aug 23 19:35:07 2011
New Revision: 1160863
URL: http://svn.apache.org/viewvc?rev=1160863view=rev
Log:
Add SSLProxyMachineCertificateChainFile directive and documentation for bug
50812
Modified: httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c?rev=1160863r1=1160862r2=1160863view=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c Tue Aug 23 19:35:07 2011
@@ -434,6 +434,45 @@ BOOL SSL_X509_INFO_load_path(apr_pool_t
return ok;
}
+/*
+ * Construct a stack of X509_INFO containing only certificates
+ * that have signed the provided certificate or are an intermediary
+ * signer of the certificate
+*/
+int SSL_X509_INFO_create_chain(const X509 *x509,
+ STACK_OF(X509_INFO) *ca_certs,
+ STACK_OF(X509_INFO) *chain)
+{
+int can_proceed=1;
+int len=0;
+int i;
+X509 *certificate = (X509 *)x509;
+X509_INFO *info;
+X509_NAME *cert_issuer_name, *ca_name, *ca_issuer_name;
+
+while (can_proceed) {
+can_proceed = 0;
+cert_issuer_name = X509_get_issuer_name(certificate);
+
+for (i = 0; i sk_X509_INFO_num(ca_certs); i++) {
+info = sk_X509_INFO_value(ca_certs, i);
+ca_name = X509_get_subject_name(info-x509);
+ca_issuer_name = X509_get_issuer_name(info-x509);
+
+if (X509_NAME_cmp(cert_issuer_name, ca_name) == 0) {
+/* Check for a self-signed cert (no issuer) */
+can_proceed=X509_NAME_cmp(ca_name, ca_issuer_name) == 0 ? 0
: 1;
+len++;
+certificate = info-x509;
+sk_X509_INFO_unshift(chain, info);
+break;
+}
+}
+}
+
+return len;
+}
+
The above code is manually building up a certificate chain. While it will work
for the simpler cases it cannot handle more complex chains. For example those
where several certificates have the same subject name and indicate preferences
using SKID/AKID. Also certificates can appear higher in the chain and be self
issued (matching subject/issuer) but not self signed. Admittedly such cases are
comparatively rare outside compliance tests...
So instead of manually building the chain why not handle it automatically or at
least have the option to do so? The X509_verify_cert function in OpenSSL can do
this. This has the advantage that the chain is also checked for validity (expiry
for example) and you can't send an invalid chain and have to trace why the peer
is rejecting it with a (possibly obscure) error.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
Re: svn commit: r1160863 - in /httpd/httpd/trunk: docs/manual/mod/ modules/ssl/
On 03/09/2011 07:06, Kaspar Brand wrote:
Modified: httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c?rev=1160863r1=1160862r2=1160863view=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c Tue Aug 23 19:35:07 2011
@@ -434,6 +434,45 @@ BOOL SSL_X509_INFO_load_path(apr_pool_t
return ok;
}
+/*
+ * Construct a stack of X509_INFO containing only certificates
+ * that have signed the provided certificate or are an intermediary
+ * signer of the certificate
+*/
+int SSL_X509_INFO_create_chain(const X509 *x509,
+ STACK_OF(X509_INFO) *ca_certs,
+ STACK_OF(X509_INFO) *chain)
+{
+int can_proceed=1;
+int len=0;
+int i;
+X509 *certificate = (X509 *)x509;
+X509_INFO *info;
+X509_NAME *cert_issuer_name, *ca_name, *ca_issuer_name;
+
+while (can_proceed) {
+can_proceed = 0;
+cert_issuer_name = X509_get_issuer_name(certificate);
+
+for (i = 0; i sk_X509_INFO_num(ca_certs); i++) {
+info = sk_X509_INFO_value(ca_certs, i);
+ca_name = X509_get_subject_name(info-x509);
+ca_issuer_name = X509_get_issuer_name(info-x509);
+
+if (X509_NAME_cmp(cert_issuer_name, ca_name) == 0) {
+/* Check for a self-signed cert (no issuer) */
+can_proceed=X509_NAME_cmp(ca_name, ca_issuer_name) == 0 ? 0
: 1;
+len++;
+certificate = info-x509;
+sk_X509_INFO_unshift(chain, info);
+break;
+}
+}
+}
+
+return len;
+}
+
I think it's preferrable to let OpenSSL build the chain (instead of
doing it ourselves). There's no readily available function for this,
unfortunately, but could you try something along the lines in OpenSSL's
s3_both.c:ssl3_output_cert_chain()? See
http://cvs.openssl.org/chngview?cn=18326
I.e., use X509_verify_cert(), ignore its result, but grab the chain from
the X509_STORE_CTX afterwards. (And when you're done, it's probably
wise to call ERR_clear_error, see http://cvs.openssl.org/chngview?cn=19472).
Sorry for the duplicate comment missed this.
There are a few side effects with using X509_verify_cert().
Some errors (signature error, expired certificates) should arguably logged or
even treated as fatal errors. This would be because the cause is a badly
configured server and it is better to get the user to fix their configuration
than send a certificate chain that is invalid.
In other cases you may hit problems because sometimes a certificate chain
which doesn't quite fit the PKIX definition is used. An example would be a proxy
certificate chain (for some value of proxy, not necessarily standard)
where some certificates in the chain are not CA certificates in the normal
definition (basic constraints CA=TRUE). That kind of chain cannot directly be
built up using X509_verify_cert().
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
On 03/08/2011 18:08, William A. Rowe Jr. wrote: On 8/3/2011 11:23 AM, Kaspar Brand wrote: Ok, so the initial version of that patch became relatively large: https://people.apache.org/~kbrand/mod_ssl-toolkit-support.v1.diff Even though trunk is CTR, I'm somewhat reluctant with simply going ahead and would appreciate if people could comment on this approach (e.g. if it's fine or splitting up would be preferred, etc.). In theory, the changes could be limited to the autoconf stuff - i.e., guard against OpenSSL 0.9.7 and not detect BSAFE SSL-C any longer in configure, and leave the mod_ssl code as is, mostly. I don't think that's what we want, however, so I tried to get rid of as much of the macro cruft as possible (drop ssl_toolkit_compat.h, remove obsolete ifdef'ed code and so on). My thought, it probably should be a set of commits; * Drop SSLC (first patch) * Drop OpenSSL 0.9.7 (second patch) * Drop ssl_toolkit_compat wrapper (third patch) * Warn on 0.9.7 and some 0.9.8 flavors (last patch) A data point for this effort which may be of interest... In OpenSSL 1.0.1 (unreleased) and later there is a feature to make all SSL related structures opaque and only allow them to be accessed through functions. This is enabled by setting OPENSSL_NO_SSL_INTERN before including any OpenSSL headers. The advantage of this is that any application which can be compiled with this option will retain binary compatibility through any changes to SSL internal structures. I haven't had time to try getting mod_ssl to work with this option. It is guaranteed to fail without some modification. There may well be some functionality missing in OpenSSL too. Ironically to support this you'd need to avoid some of the changes in this patch. For example: -l = strlen(SSL_CIPHER_get_name(c)); -memcpy(cp, SSL_CIPHER_get_name(c), l); +l = strlen(c-name); +memcpy(cp, c-name, l); Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Succeed compilation with FIPS
On 03/06/2011 15:51, Petr Hracek wrote: Dear developers, I have tried to find out on the web what is the correct way how to compile http2 so that it will be compliance with FIPS 140-2. I have already build up OpenSSL libraries with FIPS and development files as well. I have try to run ./configure --with-ssl=path_to_openSSL_FIPS_libraries and it seems to be good but how can I call make? like: make CC=fipsld FIPSLD_CC=gcc ? If you are linking to the OpenSSL shared libraries you don't need to do anything special at all. It is only if you do a static build that you need to use the fipsld script. You can test the build by enabling FIPS mode in the configuration file: the log file should confirm it is in FIPS mode. In that mode you shouldn't be able to connect with a non-FIPS ciphersuite such as one including RC4. Note that just compiling and enabling FIPS mode doesn't guarantee compliance: you also need to adhere to the requirements of the security policy. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: mod_ssl OCSP tuning (Re: TR of 2.3.10)
On 17/01/2011 13:39, Joe Orton wrote: On Sun, Jan 16, 2011 at 11:34:29AM +0100, Kaspar Brand wrote: On 13.12.2010 15:24, Jim Jagielski wrote: At this late in the game, I would prefer to do this post-2.3.10... safer that way. Polite reminder, according to [1]... :-) I feel it's important because it addresses PR 49784 and a few additional improvements for the OCSP checking code (for client auth). Patch v2 from December is attached again, for the sake of easier reference. Thanks a lot for the patch the prod... I've merged the config options changes with some minor tweaks (OpenSSL seems to stomp on the OCSP_* namespace so I renamed the macros): http://svn.apache.org/viewvc?rev=1059917view=rev w.r.t. the change to skip OCSP validation for valid self-signed certs, I brought this up a while back: http://www.mail-archive.com/dev@httpd.apache.org/msg38849.html and Stephen said it probably be configurable. Has common practice evolved here such that hard-coding the less strict behaviour is reasonable? I still believe it should be configurable. A root CA can be revoked for a number of reasons although key compromise has security issues if the responder certificate is part of the chain (i.e. cases #1 and #2 in that message). Apache OCSP AFAIK currently doesn't handle case #3 at all (trusting responders with keys trusted by some out of band means). There is a fix/enhancement for this (which also addresses the issue Steve Marquess brought up) in PR46037. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: SSLRequire UTF-8 characters backward compatibility
On 31/12/2010 07:52, Kaspar Brand wrote:
On 30.12.2010 13:43, Stefan Fritsch wrote:
The latter. I suggest using ASN1_STRING_print_ex() with
ASN1_STRFLGS_RFC2253 ~ASN1_STRFLGS_ESC_MSB (will escape them as
\0).
OK, makes sense.
ASN1_STRING_print_ex escapes a whole lot of other stuff, too. So this
change would also introduce an incompatibility with 2.2.x for all the
SSL_{CLIENT,SERVER}_{I,S}_DN_* variables.
Good point, I didn't consider this when I came up with the suggestion
quoted above. My new proposal would be to (only) use
ASN1_STRFLGS_ESC_CTRL | ASN1_STRFLGS_UTF8_CONVERT
for the SSL_{CLIENT,SERVER}_{I,S}_DN_* variables instead. This will
escape the control characters (0x0 through 0x1f), but not the others
listed in RFC 2253 - most of which primarily make sense when a complete
DN is rendered, not single attribute values.
This would then also be covered by the SSLOption LegacyDNStringFormat.
With the proposed change to the ASN1_STRING_print_ex flags, I think that
we could unconditionally use the new format for the
SSL_{CLIENT,SERVER}_{I,S}_DN_* variables, as there is no incompatibility
with simple strings (i.e., 7-bit characters encoded as
PRINTABLESTRINGs or IA5STRINGs). For non-ASCII characters, the current
code produces unusable results in many cases anyway, so I would not try
to retain that as a legacy string rendering.
I would like to have opinions from other people before committing this.
Yes, please - additional opinions appreciated.
Well it wont be totally compatible with the old format even if it only contains
7-bit ASCII characters. For example the tab character would be escaped.
There is a bug in OpenSSL currently for those options: it doesn't escape the
escape character itself (which it should treat as a special case and always
escape it if any other escaping is in use). That means some representations are
ambiguous with those options.
When that is fixed even 7 bit without control characters will have at least one
difference: the backslash will always appear escaped as \\.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
Re: SSLRequire UTF-8 characters backward compatibility
On 02/01/2011 18:42, Stefan Fritsch wrote: On Sunday 02 January 2011, Dr Stephen Henson wrote: There is a bug in OpenSSL currently for those options: it doesn't escape the escape character itself (which it should treat as a special case and always escape it if any other escaping is in use). That means some representations are ambiguous with those options. When that is fixed even 7 bit without control characters will have at least one difference: the backslash will always appear escaped as \\. I guess backslashes are very seldomly used in certificates. Therefore, I would just document that change for now and only add a backward compatibility option if the change turns out to be a problem for users. I'm thinking here how that might be abused. In the current broken OpenSSL code it doesn't escape a backslash with those options. So the following look identical when printed: 1. The single octet 0xFF. 2. The three character string \FF. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: mod_ssl ssl_util_stapling.c warnings
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. More significantly the code hasn't been tested extensively in the field so there may be problems that have yet to be uncovered. 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. Anyone else have any thoughts on the matter? Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: mod_ssl OCSP tuning (Re: TR of 2.3.10)
On 12/12/2010 09:28, Kaspar Brand wrote:
On 11.12.2010 20:27, Jim Jagielski wrote:
I've heard no objections, so on monday (12/13) I'll start
the TR.
Is there any chance that the attached patch might make it into
2.3.10? It includes two OCSP related changes for mod_ssl:
- addresses https://issues.apache.org/bugzilla/show_bug.cgi?id=49784
by adding two config directives (SSLOCSPResponseTimeSkew and
SSLOCSPResponseMaxAge) and defining new default values
- prevents mod_ssl from doing unnecessary OCSP checks
(valid self-issued certs, i.e. trust anchors configured through
SSLCACertificate{File,Path})
Note that mod_ssl's current hardcoded OCSP defaults for the time skew
(60 seconds) and the max age (360 seconds) are quite aggressive -
especially the latter one. As PR 49784 illustrates, real-world OCSP
responses often have a validity of one or more days, and are not updated
at 5-minute intervals. I therefore suggest to default to -1 for the max
age, and to 300 seconds for the time skew - this also matches the
defaults which are currently applied in mod_ssl's OCSP stapling code.
It also makes sense to add a directive to make the OCSP timeout configurable.
This can be done in the OCSP stapling code but not the OCSP code itself. The
current default is (I think) the same as the http request timeout which is way
too long in practice: if an OCSP responder doesn't respond in a few seconds it
isn't likely to respond at all.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
Re: Fwd: [us...@httpd] SSLRequire UTF-8 characters
On 24/11/2010 07:07, Kaspar Brand wrote:
On 20.11.2010 20:24, Stefan Fritsch wrote:
On Fri, 19 Nov 2010, Joe Orton wrote:
We could support this better by having a new set of exports:
SSL_{CLIENT,SERVER}_{I,S}_UTF8DN_*(_n)?
(or something similarly named)
which works the same as _DN_ but exports the attributes as a UTF-8 byte
seequence regardless of the underlying ASN.1 type; this would be a
relatively simple hack.
Or have a (per vhost) directive that enables conversion for all
SSL_*_S_DN_* and SSL_*_S_DN to UTF8. IMHO, this could even be enabled by
default in 2.4.
I prefer the latter approach, yes (there's already an awful lot of SSL_*
something variables).
Given the fact that mod_ssl's current behavior with non-ASCII characters
(i.e., outside the 0-127 range) is mostly undefined and/or sometimes
even erroneous (a BMPString in the subject or issuer DN will end up as
an empty SSL_*_*_DN_* variable, due to the initial null byte), I would
suggest the following solution:
- for all SSL_{CLIENT,SERVER}_{I,S}_DN_* variables, use UTF-8 by default
(i.e., adapt ssl_engine_vars.c:ssl_var_lookup_ssl_cert_dn() to convert
TeletexString, UniversalString and BMPString types to UTF8String)
- for SSL_{CLIENT,SERVER}_{I,S}_DN, don't use X509_NAME_oneline()
any more and switch to X509_NAME_print_ex() instead. What flags
should be used is probably debatable - I would recommend to go with
XN_FLAG_RFC2253 (note that using XN_FLAG_ONELINE with
X509_NAME_print_ex doesn't produce the same string as
X509_NAME_oneline, so this will break backward compatibility
in any case)
- add another parameter to the SSLOptions directive which allows
re-enabling the old string rendering for
SSL_{CLIENT,SERVER}_{I,S}_DN (so the new default would be to rely
on X509_NAME_print_ex - even for 2.2 -, but people could restore the
current behavior through this option)
It's a very good idea to avoid X509_NAME_oneline() wherever possible as it is
highly broken, can produce ambiguous output (of the Bobby Tables variety) and at
other times be just plain wrong (BMPStrings is one of many examples).
We have to retain it in OpenSSL for backwards compatibility though. I'd throw it
out tomorrow if I could get away with it.
You can get a UTF8String from most string types using ASN1_STRING_to_UTF8().
This should be adequate for most purposes: it doesn't handle the more bizarre
TeletexString shift conversions but those are rarely encountered in practice.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
Re: mod_ssl ssl_util_stapling.c warnings
On 29/11/2010 21:46, Guenter Knauf wrote: Hi Steve, ssl_util_stapling.c issues warnings / breaks when compiled with OSSL 1.0.0; MSVC warns: \modules\ssl\ssl_util_stapling.c(140) : warning C4133: '=' : incompatible types - from 'struct stack_st_OPENSSL_STRING *' to 'struct stack_st_STRING *' C:\buildprep\httpd-2.3.x.10\modules\ssl\ssl_util_stapling.c(142) : warning C4133: 'function' : incompatible types - from 'struct stack_st_STRING *' to 'struct stack_st *' C:\buildprep\httpd-2.3.x.10\modules\ssl\ssl_util_stapling.c(148) : warning C4133: 'function' : incompatible types - from 'struct stack_st_STRING *' to 'struct stack_st_OPENSSL_STRING *' and my picky CodeWarrior breaks: Compiling ssl_util_stapling.c ### mwccnlm Compiler: #File: ssl_util_stapling.c # # 140: aia = X509_get1_ocsp(x); # Error: ^ # illegal implicit conversion from 'struct stack_st_OPENSSL_STRING *' to # 'struct stack_st_STRING *' ### mwccnlm Compiler: # 142: cinf-uri = sk_STRING_pop(aia); # Error: ^ # illegal implicit conversion from 'struct stack_st_STRING *' to # 'struct stack_st *' ### mwccnlm Compiler: # 148: X509_email_free(aia); # Error: ^ # illegal implicit conversion from 'struct stack_st_STRING *' to # 'struct stack_st_OPENSSL_STRING *' Errors caused tool to abort. 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. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: mod_ssl ssl_util_stapling.c warnings
On 30/11/2010 00:03, Dr Stephen Henson wrote: On 29/11/2010 21:46, Guenter Knauf wrote: Hi Steve, ssl_util_stapling.c issues warnings / breaks when compiled with OSSL 1.0.0; MSVC warns: \modules\ssl\ssl_util_stapling.c(140) : warning C4133: '=' : incompatible types - from 'struct stack_st_OPENSSL_STRING *' to 'struct stack_st_STRING *' C:\buildprep\httpd-2.3.x.10\modules\ssl\ssl_util_stapling.c(142) : warning C4133: 'function' : incompatible types - from 'struct stack_st_STRING *' to 'struct stack_st *' C:\buildprep\httpd-2.3.x.10\modules\ssl\ssl_util_stapling.c(148) : warning C4133: 'function' : incompatible types - from 'struct stack_st_STRING *' to 'struct stack_st_OPENSSL_STRING *' and my picky CodeWarrior breaks: Compiling ssl_util_stapling.c ### mwccnlm Compiler: #File: ssl_util_stapling.c # # 140: aia = X509_get1_ocsp(x); # Error: ^ # illegal implicit conversion from 'struct stack_st_OPENSSL_STRING *' to # 'struct stack_st_STRING *' ### mwccnlm Compiler: # 142: cinf-uri = sk_STRING_pop(aia); # Error: ^ # illegal implicit conversion from 'struct stack_st_STRING *' to # 'struct stack_st *' ### mwccnlm Compiler: # 148: X509_email_free(aia); # Error: ^ # illegal implicit conversion from 'struct stack_st_STRING *' to # 'struct stack_st_OPENSSL_STRING *' Errors caused tool to abort. 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. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: svn commit: r1026906 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c
On 25/10/2010 06:48, Ruediger Pluem wrote:
On 10/25/2010 12:14 AM, s...@apache.org wrote:
Author: sf
Date: Sun Oct 24 22:14:15 2010
New Revision: 1026906
URL: http://svn.apache.org/viewvc?rev=1026906view=rev
Log:
Make sure to always log an error if loading of CA certificates fails
PR: 40312
Submitted by: Paul Tiemann issues apache org ourdetour com
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?rev=1026906r1=1026905r2=1026906view=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_engine_init.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_init.c Sun Oct 24 22:14:15 2010
@@ -658,7 +658,7 @@ static void ssl_init_ctx_verify(server_r
ca_list = ssl_init_FindCAList(s, ptemp,
mctx-auth.ca_cert_file,
mctx-auth.ca_cert_path);
-if (!ca_list) {
+if (sk_X509_NAME_num(ca_list) == 0) {
Can we be sure that ca_list != NULL or that sk_X509_NAME_num can handle NULL?
sk_*_num() can always handle a NULL argument but it returns -1. So = 0 covers
all cases.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
Re: ocsp stapling global mutex
On 25/06/2010 08:10, Paul Querna wrote:
Hi,
I was playing with OCSP Stapling in 2.3.6-alpha tonight, and I noticed
that in the common case path, we will always lock a global mutex.
I don't see why this is needed for the cache hit case that uses
non-SHM cache providers.
In fact, modssl_dispatch_ocsp_request, which is called on a cache
miss, already has a serialize_request, so I'm not sure why there is a
global mutex at all, even for cache updates.
It seems that inside stapling_mutex_{on,off} in ssl_util_stapling.c,
the global mutex should only be used if (mc-stapling_cache-flags
AP_SOCACHE_FLAG_NOTMPSAFE) is true?
The reason for this is to keep the number of OCSP queries to a minimum, which is
the main purpose of stapling.
If the cached response is acceptable the mutex will lock, retrieve and unlock
which should be handled relatively quickly.
In the case of an invalid (e.g. expired) or missing cached response an instance
locks, retrieves the cached response, realises it is invalid and then attempts
to retrieve and store an updated response from the responder and finally
unlocks.
The update process could take a maybe a second or so. If the lock wasn't there
many instances on a heavily loaded server could query the responder almost
simultaneously.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
Re: svn commit: r946347 - in /httpd/test/framework/trunk/t: conf/ssl/ssl.conf.in ssl/extlookup.t ssl/require.t
On 11/06/2010 07:00, Ruediger Pluem wrote: On 05/19/2010 09:20 PM, jor...@apache.org wrote: Author: jorton Date: Wed May 19 19:20:11 2010 New Revision: 946347 URL: http://svn.apache.org/viewvc?rev=946347view=rev Log: - add test for SSLRequire PeerExtList() - test for the string-rendering hack in ssl_ext_lookup() - uses an OID stolen from the ASF OID branch; official assignment has been requested for the httpd project from akarasulu@ Modified: httpd/test/framework/trunk/t/conf/ssl/ssl.conf.in httpd/test/framework/trunk/t/ssl/extlookup.t httpd/test/framework/trunk/t/ssl/require.t Index: lib/Apache/TestSSLCA.pm === --- lib/Apache/TestSSLCA.pm (Revision 946346) +++ lib/Apache/TestSSLCA.pm (Revision 946347) @@ -243,6 +243,7 @@ [ comment ] nsComment = This Is A Comment +1.3.6.1.4.1.18060.12.0 = ASN1:UTF8String:Lemons This fails with openssl 0.9.7a on Redhat 4. It will do: that syntax needs the mini-ASN1 compiler which first appeared in OpenSSL 0.9.8. Including the raw encoding with the DER option should work on all versions, you can generate that with asn1parse in OpenSSL 0.9.8. FYI it is: 0c 06 4c 65 6d 6f 6e 73 Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: svn commit: r949676 - /httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c
On 31/05/2010 08:20, rpl...@apache.org wrote:
Author: rpluem
Date: Mon May 31 07:20:21 2010
New Revision: 949676
URL: http://svn.apache.org/viewvc?rev=949676view=rev
Log:
* Fix compiler warning about incompatible pointer type
Modified:
httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c
Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c?rev=949676r1=949675r2=949676view=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c Mon May 31 07:20:21 2010
@@ -785,7 +785,7 @@ void modssl_var_extract_dns(apr_table_t
* success and writes the string to the given bio. */
static int dump_extn_value(BIO *bio, ASN1_OCTET_STRING *str)
{
-const unsigned char *pp = str-data;
+unsigned char *pp = str-data;
ASN1_STRING *ret = ASN1_STRING_new();
int rv = 0;
This actually depends on the version of OpenSSL in use. The ASN1 decoding
functions were constified in 1.0.0 so you get a warning in 1.0.0 if you make
that change or in 0.9.8 with the original...
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On 31/05/2010 22:10, Sander Temme wrote: Please note that no released version of Apache knows how to put OpenSSL into FIPS mode. When your Many Users run Apache in a situation with FIPS requirements, which and whose patches do they use? Work on FIPS integration at Apache itself stalled in 2007: http://svn.apache.org/viewvc/httpd/sandbox/gaithersburg/README-FIPS?view=log That comment refers to the older 1.1 module which was has been superseded by the 1.2 validation. I submitted a patch for the 1.2 module and support is now in trunk and a backport proposed to 2.2.x, see the SSLFIPS directive. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: RFC: drop support for OpenSSL 1.0 in trunk/2.3?
On 25/05/2010 13:45, Joe Orton wrote: I'd like to drop support for versions of OpenSSL older than 1.0 in the trunk mod_ssl. We have 200+ lines of compat macro junk and still six different compiler warnings remain in a trunk build against 1.0.0. pro: simplify code: remove ssl_toolkit_compat.h and all compat macro mess which litters the code pro: simplify testing: no longer have to test/worry about regressing builds against N subtly different versions of the OpenSSL API all pro: can drop the internal CRL revocation code in favour of OpenSSL's pro: users will be encouraged to upgrade to a modern OpenSSL which has secure TLS reneg con: trunk/2.3 won't build on all platforms/distros which ship natively with OpenSSL 1.0 (duh) con: I presume this will mean dropping support for the RSA/... toolkits, if they even work still, which I very much doubt So... love/hate? con: means FIPS 140-2 support would be dropped too. FIPS 140-2 is not supported in 1.0.0, only 0.9.8 (well 0.9.7 too but we recommend everyone use the 1.2 module with 0.9.8 if possible). If you'd said 0.9.8m (because 0.9.8m and later support reneg extension) I'd be very much in favour. I haven't checked but are there many remaining toolkit issues with supporting 0.9.8m and later? The CRL revocation checking in 0.9.8 is more primitive than 1.0.0 but still should be better than the broken manual stuff mod_ssl uses. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: [vote] release 2.2.15?
William A. Rowe Jr. wrote: On 3/3/2010 11:50 AM, Stefan Fritsch wrote: On Wednesday 03 March 2010, Mladen Turk wrote: BTW, I wouldn't recommend to compile against 0.9.8m. openssl s_client 0.9.8m block on renegotiation Have you only tried 0.9.8l as client? It has a known bug with renegotiation that makes it hang instead of fail. I have no problems with 0.9.8c and 0.9.8g (from Debian 4.0 and 5.0). If SSLInsecureRenegotiation is on, it works. If SSLInsecureRenegotiation is off, I get an sslv3 alert handshake failure. And the bug is specific to openssl 0.9.8m mishandling the alert; it will neither abort nor resume the prior session, so it is left to timeout. You may want to contrast this behavior to legacy IE, Firefox, etc. Attached is one suggestion of a workaround. If I understand the code correctly it looks like Apache is already trapping and aborting client initiated renegotiations so this hang situation shouldn't arise. Note that you don't need to abort if secure renegotiation is supported by the client. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: [vote] release 2.2.15?
Joe Orton wrote: On Wed, Mar 03, 2010 at 06:31:36PM +, Dr Stephen Henson wrote: Note that you don't need to abort if secure renegotiation is supported by the client. Is there any technical need to support client-initiated reneg? It's a bad fit with mod_ssl. It has been reported that some clients (not OpenSSL based unless the application explicitly requests it) do renegotiate periodically. In one case sending back the no renegotiation alert to an unpatched client (*definitely* not OpenSSL based) meant the connection continued correctly. I've no idea how widespread this is though. It's something which just worked before and there'd be no reason to notice it. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
OCSP stapling bug #48447
All, just to draw your attention to bug #48447. Without it OCSP stapling doesn't work at all unless a port is explicitly stated in URLs. The fix is trivial and uses the same technique as the regular client certificate OCSP code. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: Failures in SSL tests in test suite
Jeff Trawick wrote: On Sat, Dec 12, 2009 at 12:26 PM, Jeff Trawick traw...@gmail.com wrote: On Thu, Dec 10, 2009 at 3:28 PM, Ruediger Pluem rpl...@apache.org wrote: Apparently because of the fix in openssl for the TLS renegotiation issue the following failed tests now pop up in our test suite (trunk and 2.2.x the same): Failed Test Stat Wstat Total Fail List of Failed --- t/ssl/basicauth.t32 2-3 t/ssl/env.t 30 15 16-30 t/ssl/extlookup.t22 1-2 t/ssl/fakeauth.t 32 2-3 t/ssl/pr12355.t 10 10 1-10 t/ssl/pr43738.t 44 1-4 t/ssl/proxy.t 172 10 3-7 116-120 t/ssl/require.t 52 2 5 t/ssl/varlookup.t 72 72 1-72 t/ssl/verify.t 31 2 4 tests and 2 subtests skipped. I picked up almost identical failures on 2.2.14 on OpenSolaris when moving to a dev build with 0.9.8l from a dev build with 0.9.8k. At least a few of those testcases mention renegotiation. As I also picked up another failure that didn't seem to be related, I'll try to find time to perform before/after testing with just the OpenSSL k-l change. A straight k-l comparison shows exactly the same failures as you with httpd trunk/apr[-util] 1.4 HEAD on a recent OpenSolaris dev build. I'd suggest you try OpenSSL 0.9.8-dev (i.e. a recent snapshot). Renegotiation is now possible but only with itself (which presumably that tests). The only thing that is not allowed is renegotiation with the deprecated SSLv2. If there are still any problems I'll check them. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: TLS renegotiation disabling : mod_ssl and OpenSSL 0.9.8l
Jean-Marc Desperrier wrote: Dr Stephen Henson wrote: Jean-Marc Desperrier wrote: Joe Orton wrote: Please file a bug and attach all of: a) error_log output at LogLevel debug for that case b) the config snipping that you're using for /authentication c) the mod_ssl configuration This is now done in bug https://issues.apache.org/bugzilla/show_bug.cgi?id=48215 error.log might have enough info to understand what happens, but I included everything else needed to repro from scratch. What happens with the latest 0.9.8-stable version of OpenSSL? Stephen, what result do you expect from this ? Basically to rule out ticket issues other things fixed in 0.9.8-stable. A number of session ticket fixes are in 0.9.8-stable but not in 0.9.8l. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: TLS renegotiation disabling : mod_ssl and OpenSSL 0.9.8l
Jean-Marc Desperrier wrote: Joe Orton wrote: Please file a bug and attach all of: a) error_log output at LogLevel debug for that case b) the config snipping that you're using for /authentication c) the mod_ssl configuration This is now done in bug https://issues.apache.org/bugzilla/show_bug.cgi?id=48215 error.log might have enough info to understand what happens, but I included everything else needed to repro from scratch. What happens with the latest 0.9.8-stable version of OpenSSL? Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: Server Gated Certs (Was: TLS renegotiation attack, mod_ssl and OpenSSL)
Dirk-Willem van Gulik wrote: Dirk-Willem van Gulik wrote: Actually Steve - you may know - what besides the obvious extendedKeyUsage=nsSGC,msSGC in the extension file needs to go into a sub-ca below a self-signed-root-chain to make the browsers dance ? Or have they hardcoded in some specific CA or similar ? Or is there a test case in opnessl which is useful here ? As that would let us do decent tests script. Hmm - just found http://www.modssl.org/docs/apachecon2001/slide-010-n.html which seems to be one of the few places on the web; which suggest that sepcial tagging in the browser is happening on a per-CA level. Is that indeed the case. That would suggest that we do need the help of a CA to do proper testing. Actually now I think of this there is another issue. In SGC/Step Up an export grade browser would first connect using weak crypto (because that was the strongest algorithm it would support generally) and (if the certificate was authorised) step up to strong crypto. Now that browsers can connect with strong crypto from the start there isn't a great deal of point doing that any more. In fact there's a good reason not to: the double handshake with Step Up ends up perfomring two expensive server private key operations compared to one in a normal handshake. Do any countries still have browsers restricted to weak crypto and that might use Step Up or SGC? If so you also need an appropriate browser to test it... Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
