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 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: [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 > > 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: 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? (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
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: [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 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 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 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 20:14, Trevor Perrin wrote: > On Mon, Oct 21, 2013 at 5:45 AM, Dr Stephen Henson > 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 Mon, Oct 21, 2013 at 5:45 AM, Dr Stephen Henson 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 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 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 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
> 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 13/10/13 10:29, Kaspar Brand wrote: On 11.10.2013 13:53, Dr Stephen Henson wrote: IMHO though there needs to be a way to be able to tie a directive to a certificate in mod_ssl anyway though. I'm surprised no one has needed to do that before. I'm not sure we really need this for mod_ssl, as configuring more than one cert per vhost is probably a very rare case (the number of non-RSA certs on public sites is extremely small - in the 2010 SSL Survey from Qualys e.g., a few more than 100 out of 600,000 were DSA [1]). If people deliberately want to go for something other than RSA, I would assume that they either omit the RSA cert completely, or set up a dedicated vhost for (EC)DSA. Kaspar, I don't think data from 2010 (or even data from today) should be assumed to be a reliable indicator of future use of non-RSA certs on public sites. AFAICT, interest (amongst the commercial CAs) in ECC certs continues to grow. Since a significant proportion (I estimate ~20%) of deployed clients will accept RSA server certs but not ECC server certs, I think that configuring both an ECC cert and an RSA cert on a single vhost may yet become popular! -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online
Re: [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 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_ 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 Thu, Oct 10, 2013 at 4:44 PM, Dr Stephen Henson 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_ 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 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 > > > OpenSSLConfCmd KeyFile foo.key > OpenSSLConfCmd CertificateFile foo.crt > OpenSSLConfCmd ServerInfoFile foo.pem > OpenSSLConfCmd KeyFile bar.key > OpenSSLConfCmd CertificateFile bar.crt > OpenSSLConfCmd ServerInfoFile bar.pem > > > 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 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 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 OpenSSLConfCmd KeyFile foo.key OpenSSLConfCmd CertificateFile foo.crt OpenSSLConfCmd ServerInfoFile foo.pem OpenSSLConfCmd KeyFile bar.key OpenSSLConfCmd CertificateFile bar.crt OpenSSLConfCmd ServerInfoFile bar.pem 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 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_ 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_ 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 Wed, Oct 9, 2013 at 6:52 AM, Dr Stephen Henson 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 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 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
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 wrote: > > > On Tue, Oct 1, 2013 at 3:15 AM, Dr Stephen Henson > 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 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 01/10/2013 05:53, Trevor Perrin wrote: > On Sun, Sep 29, 2013 at 1:06 AM, Kaspar Brand 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 Sun, Sep 29, 2013 at 1:06 AM, Kaspar Brand 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 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 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 27.09.2013 20:58, Trevor Perrin wrote: > On Fri, Sep 27, 2013 at 9:16 AM, Kaspar Brand 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 Fri, Sep 27, 2013 at 9:16 AM, Kaspar Brand 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 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 Tue, Sep 24, 2013 at 10:39 PM, 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? 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
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: [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 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 >
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)
[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