Re: [PATCH 55593] Add SSLServerInfoFile directive
On Fri, Jan 3, 2014 at 6:17 PM, Dr Stephen Henson shen...@opensslfoundation.com wrote: 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. Thanks for that. I don't have anything useful to test with the ServerInfoFile right at the moment, but the code seems to be there now: [Sat Jan 04 14:17:37 2014] [emerg] [pid 1950:139787856742272:1950] ssl_engine_init.c(1320): AH02407: SSLOpenSSLConfCmd ServerInfoFile /home/trawick/inst/25-64/info1.pem failed for www.example.com:8443 [Sat Jan 04 14:17:37 2014] [emerg] [pid 1950:139787856742272:1950] ssl_engine_init.c(1321): SSL Library Error: error:0906D06C:PEM routines:PEM_read_bio:no start line (Expecting: DH PARAMETERS) -- Bad file contents or format - or even just a forgotten SSLCertificateKeyFile? [Sat Jan 04 14:17:37 2014] [emerg] [pid 1950:139787856742272:1950] ssl_engine_init.c(1321): SSL Library Error: error:0906D06C:PEM routines:PEM_read_bio:no start line (Expecting: EC PARAMETERS) -- Bad file contents or format - or even just a forgotten SSLCertificateKeyFile? [Sat Jan 04 14:17:37 2014] [emerg] [pid 1950:139787856742272:1950] ssl_engine_init.c(1321): SSL Library Error: error:0906D06C:PEM routines:PEM_read_bio:no start line -- Bad file contents or format - or even just a forgotten SSLCertificateKeyFile? [Sat Jan 04 14:17:37 2014] [emerg] [pid 1950:139787856742272:1950] ssl_engine_init.c(1321): SSL Library Error: error:14151185:SSL routines:SSL_CTX_use_serverinfo_file:no pem extensions Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [PATCH 55593] Add SSLServerInfoFile directive
On Tue, Oct 22, 2013 at 4:04 PM, Dr Stephen Henson shen...@opensslfoundation.com wrote: 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. 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. Thanks! 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 -- Born in Roswell... married an alien... http://emptyhammock.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: 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
Deprecating (and eventually removing) encrypted private key support in mod_ssl? (was: Re: [PATCH 55593] Add SSLServerInfoFile directive)
On 23.10.2013 16:09, Kaspar Brand wrote: On 21.10.2013 06:09, Trevor Perrin wrote: I looked at your patch. Besides lack of passphrase-handling, it breaks compatibility with existing config files (which assume certs/keys are matched by type, not order). I don't think that random order of multiple SSLCertificateFile and SSLCertificateKeyFile directives is a feature which has ever been promised in our docs. In those rare cases where people are currently configuring more than one cert per vhost, I would be quite surprised to see a config where the order of the SSLCertificateKeyFile directive does not match the one of the SSLCertificateFile directives. That would work, but someone would have to rewrite all the passphrase-handling code, Correct, and an overhaul of ssl_engine_pphrase.c is actually long due, so we shouldn't introduce more band-aid-style workarounds. Opening a new thread, as the topic isn't related to ServerInfoFile specifically. While it seams feasible to trim down - and somewhat repurpose - ssl_pphrase_Handle(), the code would still remain fairly unwieldy if support for encrypted private keys with SSLOpenSSLConfCmd PrivateKey ... is considered a feature to be preserved. 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? Instead of trying to bring up arguments myself, I'll let these two pieces speak, for the time being: http://www.symantec.com/connect/articles/apache-2-ssltls-step-step-part-2 Apache 2 with SSL/TLS: Step-by-Step, Part 2, specifically the section The passphrase dilemma http://www.trapkit.de/research/sslkeyfinder/index.html http://www.trapkit.de/research/sslkeyfinder/keyfinder_v1.0_20060205.pdf All your private keys are belong to us. Extracting RSA private keys and certificates from process memory 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 ... - maintain encrypted private key support for SSLCertificate[Key]File, but start with marking it as a deprecated (both in trunk and 2.4.x) Thanks for your opinions and comments. Kaspar P.S. As an additional data point: the docs for SSLProxyMachineCertificateFile have stated Currently there is no support for encrypted private keys since 2004, but people haven't really been screaming for this feature since then, AFAICT (see also https://issues.apache.org/bugzilla/show_bug.cgi?id=24031).
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 21.10.2013 06:09, Trevor Perrin wrote: I looked at your patch. Besides lack of passphrase-handling, it breaks compatibility with existing config files (which assume certs/keys are matched by type, not order). I don't think that random order of multiple SSLCertificateFile and SSLCertificateKeyFile directives is a feature which has ever been promised in our docs. In those rare cases where people are currently configuring more than one cert per vhost, I would be quite surprised to see a config where the order of the SSLCertificateKeyFile directive does not match the one of the SSLCertificateFile directives. That would work, but someone would have to rewrite all the passphrase-handling code, Correct, and an overhaul of ssl_engine_pphrase.c is actually long due, so we shouldn't introduce more band-aid-style workarounds. and users would have to switch to a new set of commands for working with certs / keys. No, that's not what I had in mind. SSLCertificateFile and SSLCertificateKeyFile can stay (not the least to support existing configs), but SSLOpenSSLConfCmd would offer an additional way of configuring certs and keys, e.g. for those cases where more per-cert tweaking is desired. Seems like a lot of work. For example, how would the generic SSLConfCmd commands get hooked-up with passphrase handling for the key files? Based on Steve's recent work on OpenSSL-master (PrivateKey SSL_CONF command), we might reuse the ssl_pphrase_Handle_CB() callback and set it for use with SSL_CTX_set_default_passwd_cb(). This needs further examination, though. Redesigning and reimplementing all of mod_ssl's cert / key handling around SSLConfCmd is a bigger task than I can handle. I intend to work on that, and have already done some experiments with a modified/trimmed down version of ssl_pphrase_Handle(), which only keeps the tPrivateKey hash in the global SSLModConfigRec. But I still wonder if a ServerInfoFile directive would be worthwhile, in the meantime. I don't see a justification for doing that at this time, also when considering that we're currently coding against OpenSSL 1.0.2, which isn't released yet. Kaspar
Re: [PATCH 55593] Add SSLServerInfoFile directive
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. Kaspar
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 23.10.2013 16:48, Dr Stephen Henson wrote: 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. Ah, ok, I was missing the point of SSL_CONF_CTX now being necessary in ssl_cmd_SSLOpenSSLConfCmd. Creating it on first use then seems like a reasonable approach. Perhaps it would also make sense to free SSL_CONF_CTX in ssl_init_ctx_protocol after having called SSL_CONF_CTX_finish (as was done before r1534754)? Kaspar
Re: [PATCH 55593] Add SSLServerInfoFile directive
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: 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. 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). Trevor
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 Sun, Oct 13, 2013 at 2:24 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: On 13.10.2013 00:43, Trevor Perrin wrote: But maybe the easiest way to handle this is to create another hash table like tPublicCert (e.g. tServerInfoFile or tSSLConfCmd). This table could be populated in ssl_pphrase_Handle at the same time that the tPublicCert table is populated, and read in ssl_server_import_certs()? Please not... as the comment in ssl_private.h already says, This should really be fixed using a smaller structure. As a proof of concept (or proof of my theory, if you like), I'm attaching a patch which completely does without the whole ssl_pphrase_Handle dance (with the limitation of not supporting encrypted key files, currently). Hi Kaspar, I looked at your patch. Besides lack of passphrase-handling, it breaks compatibility with existing config files (which assume certs/keys are matched by type, not order). Also, I don't see an obvious way to interleave SSL_CONF ServerInfoFile commands. Provided that OpenSSL adds support for KeyFile and CertificateFile to SSL_CONF, you could simply replace the SSL_CTX_use_certificate_chain_file()/SSL_CTX_use_PrivateKey_file() calls with a replay of the whole SSL_CONF_CMD stanza, including ServerInfoFile. That would work, but someone would have to rewrite all the passphrase-handling code, and users would have to switch to a new set of commands for working with certs / keys. Seems like a lot of work. For example, how would the generic SSLConfCmd commands get hooked-up with passphrase handling for the key files? Perhaps I could just do a directive for now, and let all this be swept into a big redesign later? It depends on what your goal is. If it's a patch for your own needs, then that's fine, but I'm clearly not in support of adding this to the mod_ssl tree (not to trunk, but even less as a backport to 2.4.x). I'd like to get ServerInfo support into mod_ssl. I could add a ServerInfoFile directive pretty easily and cleanly, per previous mail. Redesigning and reimplementing all of mod_ssl's cert / key handling around SSLConfCmd is a bigger task than I can handle. If someone else is tackling that, I could add a ServerInfoFile command later. But I still wonder if a ServerInfoFile directive would be worthwhile, in the meantime. Trevor
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 14/10/13 17:28, Kaspar Brand wrote: On 14.10.13 10:51, Rob Stradling wrote: Kaspar, I don't think data from 2010 (or even data from today) should be assumed to be a reliable indicator of future use of non-RSA certs on public sites. Past performance is not indicative of future performance, as they use to say in other industries, yes. Did the situation with Certicom's licensing terms for ECC cert issuance change recently? Not that I know of. But, with or without a licence from Certicom, it's gradually starting to happen. Symantec are already issuing ECC certs [1]. Here's one for urs.microsoft.com: -BEGIN CERTIFICATE- MIIDxjCCA2ugAwIBAgIQUbq+PtTzXy8rOAsfB6suITAKBggqhkjOPQQDAjB7MQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLDAqBgNVBAMTI1N5bWFudGVjIENs YXNzIDMgRUNDIDI1NiBiaXQgU1NMIENBMB4XDTEzMDkyMDAwMDAwMFoXDTE1MDkx OTIzNTk1OVowgYYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApXYXNoaW5ndG9uMRAw DgYDVQQHDAdSZWRtb25kMR4wHAYDVQQKDBVNaWNyb3NvZnQgQ29ycG9yYXRpb24x FDASBgNVBAsMC1NtYXJ0U2NyZWVuMRowGAYDVQQDDBF1cnMubWljcm9zb2Z0LmNv bTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABKRpJylWRGyj0IxBH+SMdRRioQd6 M6mSEDsnrnoLAeQmtJOOeGtafnrX4REkM9ZtsAWBWdynIAIFfBrcEb490+mjggHD MIIBvzA0BgNVHREELTArghF1cnMubWljcm9zb2Z0LmNvbYIWYmV0YS51cnMubWlj cm9zb2Z0LmNvbTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAU BggrBgEFBQcDAQYIKwYBBQUHAwIwQwYDVR0gBDwwOjA4BgpghkgBhvhFAQc2MCow KAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwHwYDVR0j BBgwFoAUdXGf/eTFGkqYm6v7wTqsTdTPb4wwTwYDVR0fBEgwRjBEoEKgQIY+aHR0 cDovL1NWUjI1NlNlY3VyZUVDQy1jcmwud3Muc3ltYW50ZWMuY29tL1NWUjI1NlNl Y3VyZUVDQy5jcmwwgZUGCCsGAQUFBwEBBIGIMIGFMDcGCCsGAQUFBzABhitodHRw Oi8vU1ZSMjU2U2VjdXJlRUNDLW9jc3Aud3Muc3ltYW50ZWMuY29tMEoGCCsGAQUF BzAChj5odHRwOi8vU1ZSMjU2U2VjdXJlRUNDLWFpYS53cy5zeW1hbnRlYy5jb20v U1ZSMjU2U2VjdXJlRUNDLmNlcjAKBggqhkjOPQQDAgNJADBGAiEAxdqO/Zo0L4tY +1VIXjyDBiWexXHo/LUwxJqWYK1DN/ECIQCcp+fXwMAOiv4OlvHjV3BrNuEdr93m WLuIyEC12xJ5uw== -END CERTIFICATE- AFAICT, interest (amongst the commercial CAs) in ECC certs continues to grow. Since a significant proportion (I estimate ~20%) of deployed clients will accept RSA server certs but not ECC server certs, I think that configuring both an ECC cert and an RSA cert on a single vhost may yet become popular! I'm not saying we should no longer support multiple certs per vhost (in fact, with my PoC patch, you can send as many certs to OpenSSL if you increase SSL_AIDX_MAX - though OpenSSL currently can't really cope with it)... what I'm saying is that I don't see a need for an additional per-cert directive. To support the current cert concept of OpenSSL for the SSL_CTX calls, we just need to make sure that we're applying the OpenSSLConfCmd directives (ServerInfoFile etc.) at the proper place. Kaspar Ah, I see. Thanks for explaining. [1] http://www.symantec.com/connect/blogs/introducing-algorithm-agility-ecc-and-dsa -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 13/10/13 10:29, Kaspar Brand wrote: On 11.10.2013 13:53, Dr Stephen Henson wrote: IMHO though there needs to be a way to be able to tie a directive to a certificate in mod_ssl anyway though. I'm surprised no one has needed to do that before. I'm not sure we really need this for mod_ssl, as configuring more than one cert per vhost is probably a very rare case (the number of non-RSA certs on public sites is extremely small - in the 2010 SSL Survey from Qualys e.g., a few more than 100 out of 600,000 were DSA [1]). If people deliberately want to go for something other than RSA, I would assume that they either omit the RSA cert completely, or set up a dedicated vhost for (EC)DSA. Kaspar, I don't think data from 2010 (or even data from today) should be assumed to be a reliable indicator of future use of non-RSA certs on public sites. AFAICT, interest (amongst the commercial CAs) in ECC certs continues to grow. Since a significant proportion (I estimate ~20%) of deployed clients will accept RSA server certs but not ECC server certs, I think that configuring both an ECC cert and an RSA cert on a single vhost may yet become popular! snip -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: [PATCH 55593] Add SSLServerInfoFile directive
AFAICT, interest (amongst the commercial CAs) in ECC certs continues to grow. Since a significant proportion (I estimate ~20%) of deployed clients will accept RSA server certs but not ECC server certs, I think that configuring both an ECC cert and an RSA cert on a single vhost may yet become popular! +1
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 14.10.13 10:51, Rob Stradling wrote: Kaspar, I don't think data from 2010 (or even data from today) should be assumed to be a reliable indicator of future use of non-RSA certs on public sites. Past performance is not indicative of future performance, as they use to say in other industries, yes. Did the situation with Certicom's licensing terms for ECC cert issuance change recently? AFAICT, interest (amongst the commercial CAs) in ECC certs continues to grow. Since a significant proportion (I estimate ~20%) of deployed clients will accept RSA server certs but not ECC server certs, I think that configuring both an ECC cert and an RSA cert on a single vhost may yet become popular! I'm not saying we should no longer support multiple certs per vhost (in fact, with my PoC patch, you can send as many certs to OpenSSL if you increase SSL_AIDX_MAX - though OpenSSL currently can't really cope with it)... what I'm saying is that I don't see a need for an additional per-cert directive. To support the current cert concept of OpenSSL for the SSL_CTX calls, we just need to make sure that we're applying the OpenSSLConfCmd directives (ServerInfoFile etc.) at the proper place. Kaspar
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 13.10.2013 00:43, Trevor Perrin wrote:
On Thu, Oct 10, 2013 at 4:44 PM, Dr Stephen Henson
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?
I don't see a direct way to map ssl_algo_t to the SSL_AIX_* that's
needed later. I suppose something could be kludged out of
ssl_util_algotypestr() and ssl_asn1_keystr().
But maybe the easiest way to handle this is to create another hash
table like tPublicCert (e.g. tServerInfoFile or tSSLConfCmd).
This table could be populated in ssl_pphrase_Handle at the same time
that the tPublicCert table is populated, and read in
ssl_server_import_certs()?
Please not... as the comment in ssl_private.h already says, This should
really be fixed using a smaller structure.
As a proof of concept (or proof of my theory, if you like), I'm
attaching a patch which completely does without the whole
ssl_pphrase_Handle dance (with the limitation of not supporting
encrypted key files, currently).
This would be easy to do as a directive, since only a ServerInfoFile
string would be stored in the hash table, and no OpenSSL changes are
needed.
As an SSL_CONF_CMD, there's more work:
- Add some indicator to distinguish per-cert vs global commands (?)
- Serialize/deserialize SSL_CONF_CMD name/value lists into the hashtable
- OpenSSL work:
- Implement SSL_CONF_CMD for ServerInfoFile
- Implement SSL_CONF_cmd_type(...) for relative path handling
Provided that OpenSSL adds support for KeyFile and CertificateFile to
SSL_CONF, you could simply replace the
SSL_CTX_use_certificate_chain_file()/SSL_CTX_use_PrivateKey_file() calls
with a replay of the whole SSL_CONF_CMD stanza, including ServerInfoFile.
It seems like you guys are contemplating a larger redesign of cert/key
handling based around SSL_CONF_CMD.
Perhaps I could just do a directive for now, and let all this be swept
into a big redesign later?
It depends on what your goal is. If it's a patch for your own needs,
then that's fine, but I'm clearly not in support of adding this to the
mod_ssl tree (not to trunk, but even less as a backport to 2.4.x).
Kaspar
Index: ssl_engine_init.c
===
--- ssl_engine_init.c (revision 1531623)
+++ ssl_engine_init.c (working copy)
@@ -185,6 +185,7 @@
}
#endif
+#if 0
/*
* read server private keys/public certs into memory.
* decrypting any encrypted keys via configured SSLPassPhraseDialogs
@@ -192,6 +193,7 @@
* restarts, in which case they'll live inside s-process-pool.
*/
ssl_pphrase_Handle(base_server, ptemp);
+#endif
/*
* initialize the mutex handling
@@ -835,7 +837,9 @@
if (mctx-pks) {
/* XXX: proxy support? */
+#if 0
ssl_init_ctx_cert_chain(s, p, ptemp, mctx);
+#endif
#ifdef HAVE_TLSEXT
ssl_init_ctx_tls_extensions(s, p, ptemp, mctx);
#endif
@@ -1019,6 +1023,7 @@
int have_ecc;
#endif
+#if 0
rsa_id = ssl_asn1_table_keyfmt(ptemp, vhost_id, SSL_AIDX_RSA);
dsa_id = ssl_asn1_table_keyfmt(ptemp, vhost_id, SSL_AIDX_DSA);
#ifdef HAVE_ECC
@@ -1061,6 +1066,36 @@
Oops, no KEYTYPES server private key found?!);
ssl_die(s);
}
+#else
+const char *certfile, *keyfile;
+for (i = 0; (certfile = mctx-pks-cert_files[i]) != NULL; i++) {
+if ((SSL_CTX_use_certificate_chain_file(mctx-ssl_ctx, certfile) 1))
{
+ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO()
+ Failed to configure certificate #%d for %s, check
%s,
+ i + 1, vhost_id, certfile);
+break;
+}
+keyfile = ((mctx-pks-key_files[i] != NULL) ?
+ mctx-pks-key_files[i] : certfile);
+if ((SSL_CTX_use_PrivateKey_file(mctx-ssl_ctx, keyfile,
+ SSL_FILETYPE_PEM) 1) ||
+(SSL_CTX_check_private_key(mctx-ssl_ctx) 1)) {
+ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO()
+ Failed to configure key #%d for %s, check %s,
+ i + 1, vhost_id, keyfile);
+break;
+}
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO()
+ Certificate and key #%d for %s configured from %s and
%s,
+ i + 1, vhost_id, certfile, keyfile);
+}
+if (i 1) {
+ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s, APLOGNO()
+ Failed to configure certificate and key for %s,
+ vhost_id);
+ssl_die(s);
+}
+#endif
/*
* Try to read DH parameters from the (first) SSLCertificateFile
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 11.10.2013 13:53, Dr Stephen Henson wrote: IMHO though there needs to be a way to be able to tie a directive to a certificate in mod_ssl anyway though. I'm surprised no one has needed to do that before. I'm not sure we really need this for mod_ssl, as configuring more than one cert per vhost is probably a very rare case (the number of non-RSA certs on public sites is extremely small - in the 2010 SSL Survey from Qualys e.g., a few more than 100 out of 600,000 were DSA [1]). If people deliberately want to go for something other than RSA, I would assume that they either omit the RSA cert completely, or set up a dedicated vhost for (EC)DSA. 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. Currently, it's at the end of ssl_init_ctx_protocol(), which happens still relatively early when looking at what ssl_init_ConfigureServer() does (which is used to configure a specific vhost): for server mode, ssl_init_ConfigureServer() calls ssl_init_server_ctx(), which in turn calls: ssl_init_server_check() ssl_init_ctx(), which consists of ssl_init_ctx_protocol() ssl_init_ctx_session_cache() ssl_init_ctx_callbacks() ssl_init_ctx_verify() ssl_init_ctx_cipher_suite() ssl_init_ctx_crl() ssl_init_ctx_cert_chain() ssl_init_server_certs(), which consists of ssl_server_import_cert(), once per type ssl_server_import_key(), once per type ssl_init_ticket_key() My PoC places the SSL_CTX_use_certificate_chain_file() and SSL_CTX_use_PrivateKey_file() calls in ssl_init_server_certs, which should also work fine for applying all SSL_CONF stuff with SSL_CONF_CTX_set_ssl_ctx, I think. 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. Yes and no - see the PoC I attached to my previous message, where I simply disabled the code relying on the tPublicCert and tPrivateKey hashes. As the name of ssl_pphrase_Handle() says, it's raison d'être is essentially handling encrypted private keys - and I hope that for the future, we could strip it down to the minimum required. Kaspar [1] https://www.ssllabs.com/projects/ssl-survey/index.html
Re: [PATCH 55593] Add SSLServerInfoFile directive
On Thu, Oct 10, 2013 at 4:44 PM, Dr Stephen Henson shen...@opensslfoundation.com wrote: On 10/10/2013 23:18, Trevor Perrin wrote: How would you expect the code to track the Cert - ServerInfo relationship between these points? 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. Sure. 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? I don't see a direct way to map ssl_algo_t to the SSL_AIX_* that's needed later. I suppose something could be kludged out of ssl_util_algotypestr() and ssl_asn1_keystr(). But maybe the easiest way to handle this is to create another hash table like tPublicCert (e.g. tServerInfoFile or tSSLConfCmd). This table could be populated in ssl_pphrase_Handle at the same time that the tPublicCert table is populated, and read in ssl_server_import_certs()? This would be easy to do as a directive, since only a ServerInfoFile string would be stored in the hash table, and no OpenSSL changes are needed. As an SSL_CONF_CMD, there's more work: - Add some indicator to distinguish per-cert vs global commands (?) - Serialize/deserialize SSL_CONF_CMD name/value lists into the hashtable - OpenSSL work: - Implement SSL_CONF_CMD for ServerInfoFile - Implement SSL_CONF_cmd_type(...) for relative path handling It seems like you guys are contemplating a larger redesign of cert/key handling based around SSL_CONF_CMD. Perhaps I could just do a directive for now, and let all this be swept into a big redesign later? (Yes, I'm trying to do the minimum work possible :-) Trevor
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 Wed, Oct 9, 2013 at 6:52 AM, Dr Stephen Henson shen...@opensslfoundation.com wrote: 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. Hi Stephen, Thanks a lot for your continued help. I'm trying to figure out how to do that: In ssl_engine_config.c, when a ServerInfoFile is encountered in the config file (whether directive or SSL_CONF), the code could look at sc-server-pks-cert_files to figure out the most recent SSLCertificateFile, and its index. But by ssl_engine_init.c, the certs have been read, parsed, and translated into a table indexed by algorithm type, and accessed via ssl_asn1_table_get(...). How would you expect the code to track the Cert - ServerInfo relationship between these points? Trevor
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 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(). 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). Kaspar
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
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). 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...) Trevor On Thu, Oct 3, 2013 at 3:37 PM, Trevor Perrin tr...@trevp.net wrote: On Tue, Oct 1, 2013 at 3:15 AM, Dr Stephen Henson shen...@opensslfoundation.com wrote: 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. OK. So the OpenSSL 1.0.2 code may already be doing the right thing - it actually *is* storing the ServerInfo based on the current certificate, ie in SSL_CTX.pkeys[current].serverinfo. 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. OK, in light of this new info, what do you think of my original patch? https://issues.apache.org/bugzilla/show_bug.cgi?id=55593 I presume something like the following should work in httpd-ssl.conf? - SSLCertificateFile certs/cert1.pem SSLCertificateKeyFile certs/key1.pem SSLCertificateChainFile certs/intermed1.pem SSLServerInfoFile certs/E1.pem SSLCertificateFile certs/cert2.pem SSLCertificateKeyFile certs/key2.pem SSLCertificateChainFile certs/intermed2.pem SSLServerInfoFile certs/E2.pem ... (I haven't yet tested with different cert types...) Trevor
Re: [PATCH 55593] Add SSLServerInfoFile directive
On Tue, Oct 1, 2013 at 3:15 AM, Dr Stephen Henson shen...@opensslfoundation.com wrote: 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. OK. So the OpenSSL 1.0.2 code may already be doing the right thing - it actually *is* storing the ServerInfo based on the current certificate, ie in SSL_CTX.pkeys[current].serverinfo. 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. OK, in light of this new info, what do you think of my original patch? https://issues.apache.org/bugzilla/show_bug.cgi?id=55593 I presume something like the following should work in httpd-ssl.conf? - SSLCertificateFile certs/cert1.pem SSLCertificateKeyFile certs/key1.pem SSLCertificateChainFile certs/intermed1.pem SSLServerInfoFile certs/E1.pem SSLCertificateFile certs/cert2.pem SSLCertificateKeyFile certs/key2.pem SSLCertificateChainFile certs/intermed2.pem SSLServerInfoFile certs/E2.pem ... (I haven't yet tested with different cert types...) Trevor
Re: [PATCH 55593] Add SSLServerInfoFile directive
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. 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). 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. Agreed. I would also like to see SSL_CTX_use_certificate_chain_file being used instead of SSL_CTX_use_certificate, SSL_CTX_use_certificate_chain and the SSL_read_X509 OpenSSL low-level stuff mod_ssl currently has in ssl_util_ssl.c. Kaspar
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 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?? Trevor
Re: [PATCH 55593] Add SSLServerInfoFile directive
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. This would also allow us to do a little more sanity checking in ssl_engine_config.c:ssl_cmd_SSLOpenSSLConfCmd() - e.g. for invalid command names (which are currently not rejected with httpd -t... only when httpd is started). Kaspar
Re: [PATCH 55593] Add SSLServerInfoFile directive
On 27.09.2013 20:58, Trevor Perrin wrote:
On Fri, Sep 27, 2013 at 9:16 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
It could probably be handled in
ssl_engine_config.c:ssl_cmd_SSLOpenSSLConfCmd(), but this would again
mean adding specific code for ServerInfoFile.
If we're adding specific code for ServerInfoFile, would it make more
sense just to do a separate directive?
I would like to avoid that, as it would mean to extend
modssl_pk_server_t (or some other struct) whenever an additional OpenSSL
feature is added. See also this thread for some background:
https://mail-archives.apache.org/mod_mbox/httpd-dev/201202.mbox/%3C4F2A9A20.7010502%40opensslfoundation.com%3E
Define SR /path/to/server/root/
SSLOpenSSLConfCmd ServerInfoFile ${SR}relative/file/name
Hmm, are you asking the web admin to define SR? That doesn't seem
much easier then just telling them to use the absolute name:
SSLOpenSSLConfCmd ServerInfoFile /path/to/server/root/relative/file/name
We could do that in the default httpd.conf file, similar to how it was
done with http://svn.apache.org/r1401126 for DocumentRoot.
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.
Kaspar
Index: ssl_engine_config.c
===
--- ssl_engine_config.c (revision 1527187)
+++ ssl_engine_config.c (working copy)
@@ -1820,9 +1820,15 @@
const char *ssl_cmd_SSLOpenSSLConfCmd(cmd_parms *cmd, void *dcfg,
const char *arg1, const char *arg2)
{
-ssl_ctx_param_t *param;
SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
-param = apr_array_push(sc-server-ssl_ctx_param);
+ssl_ctx_param_t *param = apr_array_push(sc-server-ssl_ctx_param);
+const char *err;
+
+if (!strncmp(arg1[strlen(arg1)-4], File, 4)
+(err = ssl_cmd_check_file(cmd, arg2))) {
+ return err;
+}
+
param-name = arg1;
param-value = arg2;
return NULL;
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 26.09.2013 23:59, Trevor Perrin wrote:
It doesn't work with filenames relative to the Apache root. The patch
I submitted uses ssl_engine_config.c:ssl_cmd_check_file() to map
relative to absolute filenames. I'm not sure how you'd do that with
SSLOpenSSLConfCmd?
It could probably be handled in
ssl_engine_config.c:ssl_cmd_SSLOpenSSLConfCmd(), but this would again
mean adding specific code for ServerInfoFile. I think a simple Define
directive which sets a global variable also does the trick, i.e.
something like:
Define SR /path/to/server/root/
SSLOpenSSLConfCmd ServerInfoFile ${SR}relative/file/name
(For context: the ServerInfo file is replacing the 5878/authz file, as
it's more useful to be able to provide ServerHello extensions, instead
of 5878 extensions. I think 5878 is somewhat falling out of favor -
or at least I hope so... [1]).
So do I, yes.
Kaspar
Re: [PATCH 55593] Add SSLServerInfoFile directive
On Fri, Sep 27, 2013 at 9:16 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
On 26.09.2013 23:59, Trevor Perrin wrote:
It doesn't work with filenames relative to the Apache root. The patch
I submitted uses ssl_engine_config.c:ssl_cmd_check_file() to map
relative to absolute filenames. I'm not sure how you'd do that with
SSLOpenSSLConfCmd?
It could probably be handled in
ssl_engine_config.c:ssl_cmd_SSLOpenSSLConfCmd(), but this would again
mean adding specific code for ServerInfoFile.
If we're adding specific code for ServerInfoFile, would it make more
sense just to do a separate directive?
I think a simple Define
directive which sets a global variable also does the trick, i.e.
something like:
Define SR /path/to/server/root/
SSLOpenSSLConfCmd ServerInfoFile ${SR}relative/file/name
Hmm, are you asking the web admin to define SR? That doesn't seem
much easier then just telling them to use the absolute name:
SSLOpenSSLConfCmd ServerInfoFile /path/to/server/root/relative/file/name
Trevor
Re: [PATCH 55593] Add SSLServerInfoFile directive
On Tue, Sep 24, 2013 at 10:39 PM, Kaspar Brand httpd-dev.2...@velox.ch 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? Thanks, I tried that. It doesn't work with filenames relative to the Apache root. The patch I submitted uses ssl_engine_config.c:ssl_cmd_check_file() to map relative to absolute filenames. I'm not sure how you'd do that with SSLOpenSSLConfCmd? (For context: the ServerInfo file is replacing the 5878/authz file, as it's more useful to be able to provide ServerHello extensions, instead of 5878 extensions. I think 5878 is somewhat falling out of favor - or at least I hope so... [1]). Trevor [1] http://www.ietf.org/mail-archive/web/tls/current/msg09913.html
Re: [PATCH 55593] Add SSLServerInfoFile directive
Since you mentioned RFC 5878, I've attached a patch to issue 55467 which allows third party modules to send and receive custom TLS extensions or supplemental data (which can be used to implement support for RFC 5878), and adds reneg support as well (as some folks only want to send the extensions after the initial handshake). https://issues.apache.org/bugzilla/show_bug.cgi?id=55467 Scott On Sep 24, 2013, at 10:39 PM, Kaspar Brand httpd-dev.2...@velox.ch 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). Kaspar cmd_ServerInfoFile.diff
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
[PATCH 55593] Add SSLServerInfoFile directive
Hi Apache folks, I've been working with Ben Laurie on a ServerInfoFile feature for OpenSSL 1.0.2. Using a call to OpenSSL's SSL_CTX_use_serverinfo_file() the user can specify a file of PEM blocks containing TLS ServerHello extension data. The extensions will be returned if the client sends a corresponding ClientHello. This allows support of Certificate Transparency (RFC 6962), TACK (draft-perrin-tls-tack), and similar things. 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] Trevor [1] https://github.com/openssl/openssl/tree/OpenSSL_1_0_2-stable [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=55593
Re: [PATCH 55593] Add SSLServerInfoFile directive
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).
Kaspar
diff --git a/ssl/ssl_conf.c b/ssl/ssl_conf.c
index 1f4c4dd..2c0e356 100644
--- a/ssl/ssl_conf.c
+++ b/ssl/ssl_conf.c
@@ -365,6 +365,14 @@ static int cmd_options(SSL_CONF_CTX *cctx, const char
*value)
return CONF_parse_list(value, ',', 1, ssl_set_option_list, cctx);
}
+static int cmd_serverinfo_file(SSL_CONF_CTX *cctx, const char *value)
+ {
+ int rv = 1;
+ if (cctx-ctx)
+ rv = SSL_CTX_use_serverinfo_file(cctx-ctx, value);
+ return rv 0;
+ }
+
typedef struct
{
int (*cmd)(SSL_CONF_CTX *cctx, const char *value);
@@ -372,7 +380,7 @@ typedef struct
const char *str_cmdline;
} ssl_conf_cmd_tbl;
-/* Table of supported patameters */
+/* Table of supported parameters */
static ssl_conf_cmd_tbl ssl_conf_cmds[] = {
{cmd_sigalgs, SignatureAlgorithms, sigalgs},
@@ -384,6 +392,7 @@ static ssl_conf_cmd_tbl ssl_conf_cmds[] = {
{cmd_cipher_list, CipherString, cipher},
{cmd_protocol, Protocol, NULL},
{cmd_options, Options, NULL},
+ {cmd_serverinfo_file, ServerInfoFile, NULL},
};
int SSL_CONF_cmd(SSL_CONF_CTX *cctx, const char *cmd, const char *value)
