You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Kaspar Brand <ht...@velox.ch> on 2013/11/13 15:06:29 UTC
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?
Posted by Kaspar Brand <ht...@velox.ch>.
On 06.12.2013 01:17, Daniel Ruggeri wrote:
> On 11/14/2013 5:54 AM, Joe Orton wrote:
>> a) people who want the ability to do filesystem backups without exposing
>> private keys to the set of admins who can read such backups; or e.g.
>> stick keys on NFS mounts, a similar requirement there.
>>
>> b) people who like or are required to follow "security by checklist" or
>> "security by regulator"; some auditor has "No Plaintext Keys !!!" on the
>> checklist, and so we must not use plaintext keys, no argument.
>>
>> I'm most sceptical of all about (b) as motivation for increasing
>> software complexity, but (a) I can at least appreciate.
>
> c) Like a, the system has lots of users on it that aren't necessarily
> trusted (application developers who look at logs) that shouldn't have
> access to the key.
In terms of privileges, there isn't much of a difference between a file
with an unencrypted private readable by root only, and the fact that the
unencrypted key is kept in memory all the time.
> d) If any bug/exploit in an application running on the same box or in
> httpd is found allowing an arbitrary remote file to be read, an attacker
> could easily locate the key (since most httpd.conf files are in
> predictable locations) and read it remotely. An even worse case is a
> server admin accidentally exposing / due to ignorance and/or malice...
> but I can't really defend those guys much :-).
If any privilege escalation vulnerability exists on that system, you're
in the same situation. Encrypting private keys can't compensate for
overall insecurity of the system.
> Also worth noting, other SSL implementations protect their keys.
I don't think that's true. SSL implementations might offer support for
loading encrypted keys, but hardly any of them is programmatically
enforcing a particular way of storing private keys.
> Java,
> for example has a password on the keystore and an optional, additional
> password on the key object. I'd say that if the implementation supports
> it, httpd should try to accommodate it...
That's just how "keytool" works. If a specific utility prompts you for
passwords when creating keys, that doesn't say much about how its SSL
implementation deals with keys in general. Also, the fact that a library
has feature X, option Y or knob Z doesn't necessarily mean that we
should continue to maintain lots of unwieldy code (look at
ssl_engine_pphrase.c) to make such things sort of usable in mod_ssl.
> there is no limit to what some
> people are willing to do in order to increase their apparent security
> posture.
Ok, then I suggest they do something like I briefly outlined in my reply
to Joe: "decrypt the encrypted files to a RAM disk and let httpd load
them from there" (with all complexity they prefer, such as secret
splitting and m-out-of-n authentication etc.).
> I don't mean to say that a password protecting the file is "secure"...
> but it adds a layer, and (most) layers are good.
I don't agree. What you're bringing up is basically the defense in depth
argument (which I don't dispute in general), but adding a layer which
doesn't really provide additional protection is not only useless, but
harmful, since it conveys the wrong message to the user.
Kaspar
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl?
Posted by Daniel Ruggeri <DR...@primary.net>.
On 12/5/2013 6:17 PM, Daniel Ruggeri wrote:
> On 11/14/2013 5:54 AM, Joe Orton wrote:
>> a) people who want the ability to do filesystem backups without exposing
>> private keys to the set of admins who can read such backups; or e.g.
>> stick keys on NFS mounts, a similar requirement there.
>>
>> b) people who like or are required to follow "security by checklist" or
>> "security by regulator"; some auditor has "No Plaintext Keys !!!" on the
>> checklist, and so we must not use plaintext keys, no argument.
>>
>> I'm most sceptical of all about (b) as motivation for increasing
>> software complexity, but (a) I can at least appreciate.
> c) Like a, the system has lots of users on it that aren't necessarily
> trusted (application developers who look at logs) that shouldn't have
> access to the key.
>
> d) If any bug/exploit in an application running on the same box or in
> httpd is found allowing an arbitrary remote file to be read, an attacker
> could easily locate the key (since most httpd.conf files are in
> predictable locations) and read it remotely. An even worse case is a
> server admin accidentally exposing / due to ignorance and/or malice...
> but I can't really defend those guys much :-).
>
> Also worth noting, other SSL implementations protect their keys. Java,
> for example has a password on the keystore and an optional, additional
> password on the key object. I'd say that if the implementation supports
> it, httpd should try to accommodate it... there is no limit to what some
> people are willing to do in order to increase their apparent security
> posture.
>
> --
> Daniel Ruggeri
>
I don't mean to say that a password protecting the file is "secure"...
but it adds a layer, and (most) layers are good.
--
Daniel Ruggeri
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl?
Posted by Daniel Ruggeri <DR...@primary.net>.
On 11/14/2013 5:54 AM, Joe Orton wrote:
> a) people who want the ability to do filesystem backups without exposing
> private keys to the set of admins who can read such backups; or e.g.
> stick keys on NFS mounts, a similar requirement there.
>
> b) people who like or are required to follow "security by checklist" or
> "security by regulator"; some auditor has "No Plaintext Keys !!!" on the
> checklist, and so we must not use plaintext keys, no argument.
>
> I'm most sceptical of all about (b) as motivation for increasing
> software complexity, but (a) I can at least appreciate.
c) Like a, the system has lots of users on it that aren't necessarily
trusted (application developers who look at logs) that shouldn't have
access to the key.
d) If any bug/exploit in an application running on the same box or in
httpd is found allowing an arbitrary remote file to be read, an attacker
could easily locate the key (since most httpd.conf files are in
predictable locations) and read it remotely. An even worse case is a
server admin accidentally exposing / due to ignorance and/or malice...
but I can't really defend those guys much :-).
Also worth noting, other SSL implementations protect their keys. Java,
for example has a password on the keystore and an optional, additional
password on the key object. I'd say that if the implementation supports
it, httpd should try to accommodate it... there is no limit to what some
people are willing to do in order to increase their apparent security
posture.
--
Daniel Ruggeri
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl?
Posted by Kaspar Brand <ht...@velox.ch>.
On 05.01.2014 15:09, Dr Stephen Henson wrote:
> One the subject of 1.0.2 would it be appropriate to set auto ecdh parameter
> selection as the default in mod_ssl where supported? As things stand one single
> curve can be set (with default P-256) and it's an all or nothing choice, with
> auto parameter selection the highest priority curve supported by both sides is used.
For ephemeral keys, you mean? So something like the below in ssl_init_server_certs?
I think that would make sense if the admin did not explicitly configure a single
curve (together with the "Curves" SSL_CONF command, this should allow "to configure
a list of curve names [...] (from which OpenSSL would then pick the first which
intersects with the elliptic_curves extension from the ClientHello)", as mentioned
in [1], right?).
Kaspar
[1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3C52369430.3050807@velox.ch%3E
--- modules/ssl/ssl_engine_init.c (revision 1555662)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -1020,11 +1020,16 @@ static apr_status_t ssl_init_server_certs(server_r
OBJ_nid2sn(nid), vhost_id, certfile);
}
/*
- * ...otherwise, configure NIST P-256 (required to enable ECDHE)
+ * ...otherwise, enable auto curve selection (OpenSSL 1.0.2 and later)
+ * or configure NIST P-256 (required to enable ECDHE for earlier versions)
*/
else {
+#if defined(SSL_CTX_set_ecdh_auto)
+ SSL_CTX_set_ecdh_auto(mctx->ssl_ctx, 1);
+#else
SSL_CTX_set_tmp_ecdh(mctx->ssl_ctx,
EC_KEY_new_by_curve_name(NID_X9_62_prime256v1));
+#endif
}
#endif
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl?
Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.
On 05/01/2014 09:00, Kaspar Brand wrote:
> On 03.01.2014 23:51, Dr Stephen Henson wrote:
>> On 28/12/2013 13:34, Kaspar Brand wrote:
>>> FYI: in r1553824 (which I just committed to trunk), I'm now manually
>>> shuffling things around to support per-cert chains - but would happily
>>> drop the "#if defined(SSL_CTX_set1_chain)"-enclosed code if you decide
>>> to adapt SSL_CTX_use_certificate_chain_file in 1.0.2.
>>>
>>
>> Now done for OpenSSL master and 1.0.2 branches.
>
> Thanks, I have removed the code in r1555463 therefore. Assuming that the
> release of 1.0.2 isn't too far away by now, I have added a backport
> proposal for 2.4.x. Votes/reviews welcome. (And while I have your
> attention: could you perhaps have a look at OpenSSL's PRs #3178 and
> #3183? Both would help in improving SNI-based configurations.)
>
OK I'll have a look at those.
One the subject of 1.0.2 would it be appropriate to set auto ecdh parameter
selection as the default in mod_ssl where supported? As things stand one single
curve can be set (with default P-256) and it's an all or nothing choice, with
auto parameter selection the highest priority curve supported by both sides is used.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shenson@opensslfoundation.com
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl?
Posted by Kaspar Brand <ht...@velox.ch>.
On 03.01.2014 23:51, Dr Stephen Henson wrote:
> On 28/12/2013 13:34, Kaspar Brand wrote:
>> FYI: in r1553824 (which I just committed to trunk), I'm now manually
>> shuffling things around to support per-cert chains - but would happily
>> drop the "#if defined(SSL_CTX_set1_chain)"-enclosed code if you decide
>> to adapt SSL_CTX_use_certificate_chain_file in 1.0.2.
>>
>
> Now done for OpenSSL master and 1.0.2 branches.
Thanks, I have removed the code in r1555463 therefore. Assuming that the
release of 1.0.2 isn't too far away by now, I have added a backport
proposal for 2.4.x. Votes/reviews welcome. (And while I have your
attention: could you perhaps have a look at OpenSSL's PRs #3178 and
#3183? Both would help in improving SNI-based configurations.)
Kaspar
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl?
Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.
On 28/12/2013 13:34, Kaspar Brand wrote:
> On 18.11.2013 18:42, Kaspar Brand wrote:
>> On 18.11.2013 15:38, Dr Stephen Henson wrote:
>>> For OpenSSL 1.0.2 this limitation is removed and you can have different chains
>>> for each certificate type (and for SSL structures too) and it just uses the
>>> right one. This uses the function SSL_CTX_add1_chain_cert which adds a
>>> certificate to the chain for the current certificate.
>>>
>>> I *could* change SSL_CTX_use_certificate_chain_file to use
>>> SSL_CTX_add1_chain_cert instead of SSL_CTX_add_extra_chain_cert or perhaps have
>>> a different function. I'm always cautious about changing the behaviour of
>>> existing functions though as the most innocent change will usually break
>>> *something*, though I can't see how it can in this case.
>>
>> I would be in favor this change for 1.0.2 - to me that would be more
>> like a "fix" of SSL_CTX_use_certificate_chain_file than a change in
>> behavior, actually.
>
> FYI: in r1553824 (which I just committed to trunk), I'm now manually
> shuffling things around to support per-cert chains - but would happily
> drop the "#if defined(SSL_CTX_set1_chain)"-enclosed code if you decide
> to adapt SSL_CTX_use_certificate_chain_file in 1.0.2.
>
Now done for OpenSSL master and 1.0.2 branches.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shenson@opensslfoundation.com
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl?
Posted by Kaspar Brand <ht...@velox.ch>.
On 18.11.2013 18:42, Kaspar Brand wrote:
> On 18.11.2013 15:38, Dr Stephen Henson wrote:
>> For OpenSSL 1.0.2 this limitation is removed and you can have different chains
>> for each certificate type (and for SSL structures too) and it just uses the
>> right one. This uses the function SSL_CTX_add1_chain_cert which adds a
>> certificate to the chain for the current certificate.
>>
>> I *could* change SSL_CTX_use_certificate_chain_file to use
>> SSL_CTX_add1_chain_cert instead of SSL_CTX_add_extra_chain_cert or perhaps have
>> a different function. I'm always cautious about changing the behaviour of
>> existing functions though as the most innocent change will usually break
>> *something*, though I can't see how it can in this case.
>
> I would be in favor this change for 1.0.2 - to me that would be more
> like a "fix" of SSL_CTX_use_certificate_chain_file than a change in
> behavior, actually.
FYI: in r1553824 (which I just committed to trunk), I'm now manually
shuffling things around to support per-cert chains - but would happily
drop the "#if defined(SSL_CTX_set1_chain)"-enclosed code if you decide
to adapt SSL_CTX_use_certificate_chain_file in 1.0.2.
Kaspar
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl?
Posted by Kaspar Brand <ht...@velox.ch>.
On 18.11.2013 15:38, Dr Stephen Henson wrote:
> Erk typo.. I of course meant "...after you call SSL_CTX_use_certificate_file or
> SSL_CTX_use_certificate_chain_file..."
Yeah this was obvious... makes me cringe as well but here we go:
https://people.apache.org/~kbrand/mod_ssl_pkey_2013-11-18_wip.patch
(interdiff attached to this message)
For the SSL_CONF_cmd loop, I had to insert a call to
ssl_stapling_init_cert as well - currently I'm testing for the
"Certificate" parameter name being set, but if there's a better way to
figure out if we need to call ssl_stapling_init_cert, I'm all ears.
> Unfortunately due to a limitation in OpenSSL 1.0.1 and earlier you can only have
> one chain for the SSL_CTX shared by all certificate types and all SSL structures
> created from it.
>
> That means if you have more than one certificate configured and they have
> different chains the second will replace the first in the SSL_CTX and it will
> end up sending the wrong chain in some cases.
Right, that's essentially what the last paragraph of the
SSLCertificateChainFile is stating
(http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatechainfile),
so I wouldn't worry too much about the behavior with releases up to 1.0.1.
> For OpenSSL 1.0.2 this limitation is removed and you can have different chains
> for each certificate type (and for SSL structures too) and it just uses the
> right one. This uses the function SSL_CTX_add1_chain_cert which adds a
> certificate to the chain for the current certificate.
>
> I *could* change SSL_CTX_use_certificate_chain_file to use
> SSL_CTX_add1_chain_cert instead of SSL_CTX_add_extra_chain_cert or perhaps have
> a different function. I'm always cautious about changing the behaviour of
> existing functions though as the most innocent change will usually break
> *something*, though I can't see how it can in this case.
I would be in favor this change for 1.0.2 - to me that would be more
like a "fix" of SSL_CTX_use_certificate_chain_file than a change in
behavior, actually.
Kaspar
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl?
Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.
On 17/11/2013 15:25, Dr Stephen Henson wrote:
>
> Evil hack workaround: create a temporary SSL structure from the SSL_CTX of
> interest after you call SSL_CTX_get_certificate, call SSL_get_certificate on it
> and then free up the temp SSL structure. That *should* work on all the versions
> of OpenSSL of interest. That's not very efficient and makes me cringe a bit but
> you'd only go through it once on start up.
>
Erk typo.. I of course meant "...after you call SSL_CTX_use_certificate_file or
SSL_CTX_use_certificate_chain_file..."
A point to note about SSL_CTX_use_certificate_chain_file, at least in its
current form.
If the certificate file contains additional certificates this will end up adding
them to the SSL_CTX using SSL_CTX_add_extra_chain_cert. That is more efficient
as it doesn't have to try and build the chain on each call.
Unfortunately due to a limitation in OpenSSL 1.0.1 and earlier you can only have
one chain for the SSL_CTX shared by all certificate types and all SSL structures
created from it.
That means if you have more than one certificate configured and they have
different chains the second will replace the first in the SSL_CTX and it will
end up sending the wrong chain in some cases.
For OpenSSL 1.0.2 this limitation is removed and you can have different chains
for each certificate type (and for SSL structures too) and it just uses the
right one. This uses the function SSL_CTX_add1_chain_cert which adds a
certificate to the chain for the current certificate.
I *could* change SSL_CTX_use_certificate_chain_file to use
SSL_CTX_add1_chain_cert instead of SSL_CTX_add_extra_chain_cert or perhaps have
a different function. I'm always cautious about changing the behaviour of
existing functions though as the most innocent change will usually break
*something*, though I can't see how it can in this case.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shenson@opensslfoundation.com
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl?
Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.
On 17/11/2013 15:01, Kaspar Brand wrote:
>
> One issue I'm facing with the current implementation is that when
> relying on SSL_CTX_use_certificate_file/
> SSL_CTX_use_certificate_chain_file to configure the cert, there's no way
> to get at the X509 * which really got configured for the SSL_CTX
> (remember that we're compiling with OPENSSL_NO_SSL_INTERN for OpenSSL
> 1.0.0 or later).
>
I don't think it helps if you don't use OPENSSL_NO_SSL_INTERN either. The actual
certificate configured is in a CERT structure (which can be part of SSL_CTX or
SSL structures) which is defined in a private header file.
> Steve, could you consider adding SSL_CTX_get_certificate, which would
> allow retrieving the "current cert" (i.e. one set by the last
> SSL_CTX_use_certificate* call)? And perhaps SSL_CTX_get_privatekey as
> its companion, at the same time? Without SSL_CTX_get_certificate at
> least, we can't call ssl_stapling_init_cert, unfortunately.
>
I can certainly add functions to OpenSSL 1.0.2 and later, I'd regard it as a
useful addition. It's problematical adding it to earlier releases as we have a
"no new functionality" policy for bug fix releases.
Evil hack workaround: create a temporary SSL structure from the SSL_CTX of
interest after you call SSL_CTX_get_certificate, call SSL_get_certificate on it
and then free up the temp SSL structure. That *should* work on all the versions
of OpenSSL of interest. That's not very efficient and makes me cringe a bit but
you'd only go through it once on start up.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shenson@opensslfoundation.com
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl?
Posted by Kaspar Brand <ht...@velox.ch>.
On 14.11.2013 12:54, Joe Orton wrote:
> I've also always been a sceptic of this (mis)feature, so I hate to be
> one to defend it. But demand comes from:
>
> a) people who want the ability to do filesystem backups without exposing
> private keys to the set of admins who can read such backups; or e.g.
> stick keys on NFS mounts, a similar requirement there.
Hmm ok, these can be considered (IMO somewhat contrived) use cases,
though I think it's possible to suggest workarounds should we decide to
completely drop support for encrypted private keys (e.g. exclude the
unencrypted key from the backup, and store an encrypted one in parallel
/ decrypt the encrypted files to a RAM disk and let httpd load them from
there and similar).
Let me note that that "other" popular open-source HTTP server doesn't
have any useful support for encrypted private keys... it will just pop
up OpenSSL's default "Enter PEM pass phrase:" prompt (once for each
ssl_certificate_key directive, with a single chance of entering the
correct pass phrase for each), and on receiving SIGHUP will simply abort
the config reload. IOW, lack of support for encrypted private keys does
not seem like a "must have" feature for an HTTP server these days.
> b) people who like or are required to follow "security by checklist" or
> "security by regulator"; some auditor has "No Plaintext Keys !!!" on the
> checklist, and so we must not use plaintext keys, no argument.
Oh yes these auditors I like in particular. Probably the same ones who
think that not ticking the "Mark this key as exportable" option when
importing a key into the Windows cert store does indeed prevent people
from extracting them (see
https://www.isecpartners.com/tools/application-security/jailbreak.aspx
for evidence to the contrary).
> I'm most sceptical of all about (b) as motivation for increasing
> software complexity, but (a) I can at least appreciate.
Does this mean you would object to the eventual removal of support for
encrypted private key files in mod_ssl?
To get a step further, I put a snapshot of my WIP patch for lifting the
"no more than 3 certs/keys" limit with ssl_pphrase_Handle etc. under
https://people.apache.org/~kbrand/mod_ssl_pkey_2013-11-17_wip.patch
It includes a fairly large number of changes (which I would most likely
split into smaller pieces when committing to trunk), but my hope is that
other people could give it a try and provide feedback. Brief list of
notable changes:
- do not index keys by algorithm (use a simple int index)
- repurpose ssl_pphrase_Handle as ssl_load_encrypted_pkey (and
only use when needed, i.e. when encountering an encrypted key)
- change the prompt for the "builtin" dialog to also show the
filename (but drop the algorithm type, also for the "exec" dialog)
- remove the "myCtxVarGet abomination" (replace with a pphrase_cb_arg_t
struct, which currently keeps most of the existing variable names,
for the sake of better comparability with the previous code)
- move the SSL_CONF_cmd invocations after the ssl_init_server_cert
call, so that it can be used as either a complement of
the SSLCertificate[Key]File directives, or as a substitute
(when including "PrivateKey" and "Certificate" commands)
- drop SSL_read_X509 from ssl_util_ssl.c (no longer needed)
- remove SGC related bits (SGC has been dead for years)
- drop the code for supporting SSLPKCS7CertificateFile (was never
documented, either SSLCertificateChainFile and/or SSLCertificateFile
serve the same purpose, and a PKCS#7 file can be trivially converted
into a file for use with SSLCertificateChainFile)
One issue I'm facing with the current implementation is that when
relying on SSL_CTX_use_certificate_file/
SSL_CTX_use_certificate_chain_file to configure the cert, there's no way
to get at the X509 * which really got configured for the SSL_CTX
(remember that we're compiling with OPENSSL_NO_SSL_INTERN for OpenSSL
1.0.0 or later).
Steve, could you consider adding SSL_CTX_get_certificate, which would
allow retrieving the "current cert" (i.e. one set by the last
SSL_CTX_use_certificate* call)? And perhaps SSL_CTX_get_privatekey as
its companion, at the same time? Without SSL_CTX_get_certificate at
least, we can't call ssl_stapling_init_cert, unfortunately.
Feedback would be much appreciated (in particular from people who rely
on encrypted keys and could give the patch a try with their existing
config).
Kaspar
Re: Deprecating (and eventually removing) encrypted private key
support in mod_ssl?
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Nov 14, 2013 at 07:02:58AM +0100, Kaspar Brand wrote:
> On 13.11.2013 15:28, Dr Stephen Henson wrote:
> > 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.
>
> True, it allows to SIGHUP/SIGUSR1 httpd without having to reenter a
> passphrase. But my point is a different one, actually: why do we want to
> enable users to protect file-based keys with a pass phrase in the first
> place? As the article on the Symantec (formerly Securityfocus) site
> says: "It is not only inconvenient, but also gives a false sense of
> security."
I've also always been a sceptic of this (mis)feature, so I hate to be
one to defend it. But demand comes from:
a) people who want the ability to do filesystem backups without exposing
private keys to the set of admins who can read such backups; or e.g.
stick keys on NFS mounts, a similar requirement there.
b) people who like or are required to follow "security by checklist" or
"security by regulator"; some auditor has "No Plaintext Keys !!!" on the
checklist, and so we must not use plaintext keys, no argument.
I'm most sceptical of all about (b) as motivation for increasing
software complexity, but (a) I can at least appreciate.
Regards, Joe
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl?
Posted by Kaspar Brand <ht...@velox.ch>.
On 13.11.2013 15:28, Dr Stephen Henson wrote:
> 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.
True, it allows to SIGHUP/SIGUSR1 httpd without having to reenter a
passphrase. But my point is a different one, actually: why do we want to
enable users to protect file-based keys with a pass phrase in the first
place? As the article on the Symantec (formerly Securityfocus) site
says: "It is not only inconvenient, but also gives a false sense of
security."
> Unfortunately it does this in an algorithm specific way which means the whole
> lot needs updating every time a new algorithm arrives.
That's something we can solve. My current version of
ssl_pphrase_Handle() allows configuring as many keys/certs as you see
fit (well, it then turns into an OpenSSL issue as you can only have one
ECDSA cert e.g., IINM).
> 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).
Correct. I doubt that we would want to add any HSM key activation dance
stuff into mod_ssl, this is way too vendor specific. PKCS#11 would be
the most sensible thing here, I think, but even in this case, I wonder
what benefit passphrase-protected, HSM-based keys would have.
Kaspar
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl? (was: Re: [PATCH 55593] Add "SSLServerInfoFile" directive)
Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.
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
shenson@opensslfoundation.com
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl?
Posted by Kaspar Brand <ht...@velox.ch>.
On 17.11.2013 15:43, Dr Stephen Henson wrote:
> On 13/11/2013 14:06, Kaspar Brand wrote:
>>
>> - 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?
I'm ok with how it currently behaves. In my WIP patch (see previous
message), I'm just disabling the password prompt.
> The SSL_CONF code (which SSLOpenSSLConfCmd uses) should have support for
> encrypted private keys as other applications might want to use it.
Sure, no problem with that.
> 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.
It's turning out to be quite useful for mod_ssl, and definitely helps in
exposing new OpenSSL features to httpd without the need of having to
adding new explicit code. Thanks!
Kaspar
Re: Deprecating (and eventually removing) encrypted private key support
in mod_ssl? (was: Re: [PATCH 55593] Add "SSLServerInfoFile" directive)
Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.
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
shenson@opensslfoundation.com