You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Yann Ylavic <yl...@gmail.com> on 2014/04/22 12:55:12 UTC
Re: svn commit: r1588851 - /httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
On Mon, Apr 21, 2014 at 8:39 AM, <kb...@apache.org> wrote:
> Author: kbrand
> Date: Mon Apr 21 06:39:24 2014
> New Revision: 1588851
>
> URL: http://svn.apache.org/r1588851
> Log:
> ssl_callback_TmpDH: for OpenSSL 1.0.2 and later, set the current cert to the
> one actually used for the connection before calling SSL_get_privatekey(ssl)
>
> Modified:
> httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
>
> Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=1588851&r1=1588850&r2=1588851&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
> +++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Mon Apr 21 06:39:24 2014
> @@ -1344,8 +1344,19 @@ make_get_dh(rfc3526, 4096, 2)
> DH *ssl_callback_TmpDH(SSL *ssl, int export, int keylen)
> {
> conn_rec *c = (conn_rec *)SSL_get_app_data(ssl);
> - EVP_PKEY *pkey = SSL_get_privatekey(ssl);
> - int type = pkey ? EVP_PKEY_type(pkey->type) : EVP_PKEY_NONE;
> + EVP_PKEY *pkey;
> + int type;
> +
> +#ifdef SSL_CERT_SET_SERVER
> + /*
> + * When multiple certs/keys are configured for the SSL_CTX: make sure
> + * that we get the private key which is indeed used for the current
> + * SSL connection (available in OpenSSL 1.0.2 or later only)
> + */
> + SSL_set_current_cert(ssl, SSL_CERT_SET_SERVER);
> +#endif
Shouldn't this be fixed in OpenSSL (1.0.2)?
When SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST|NEXT) is used to
scan the certs, should one use a final SSL_CTX_set_current_cert(ctx,
SSL_CERT_SET_SERVER) so that the one "inherited" by SSL_new(ctx) (if
any) gets set accordingly?
Or every callback ought to take care of this?
How about TmpDH used by client (proxy) handshake, is still
SSL_CERT_SET_SERVER the right cert?
It looks like a regression to me (which may affect several software),
the callbacks should not care about the loading order of (or previous
walking though) the certs, and the callback's given SSL current cert
be the one of the underlying authentication.
> + pkey = SSL_get_privatekey(ssl);
> + type = pkey ? EVP_PKEY_type(pkey->type) : EVP_PKEY_NONE;
>
> /*
> * OpenSSL will call us with either keylen == 512 or keylen == 1024
>
>
Regards,
Yann.
Re: svn commit: r1588851 - /httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
Posted by Kaspar Brand <ht...@velox.ch>.
On 22.04.2014 12:55, Yann Ylavic wrote:
> On Mon, Apr 21, 2014 at 8:39 AM, <kb...@apache.org> wrote:
>> +#ifdef SSL_CERT_SET_SERVER
>> + /*
>> + * When multiple certs/keys are configured for the SSL_CTX: make sure
>> + * that we get the private key which is indeed used for the current
>> + * SSL connection (available in OpenSSL 1.0.2 or later only)
>> + */
>> + SSL_set_current_cert(ssl, SSL_CERT_SET_SERVER);
>> +#endif
>
> Shouldn't this be fixed in OpenSSL (1.0.2)?
That's probably a question for Steve, but the way I understood his
comment in February was that he would rather not want it to do by
default, hence the new SSL_CERT_SET_SERVER control.
> When SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST|NEXT) is used to
> scan the certs, should one use a final SSL_CTX_set_current_cert(ctx,
> SSL_CERT_SET_SERVER) so that the one "inherited" by SSL_new(ctx) (if
> any) gets set accordingly?
That's not possible - for SSL_get_privatekey, we do not know which cert
is picked at connection time (the client can influence this by the
cipher suites he offers in the ClientHello).
> Or every callback ought to take care of this?
Unless OpenSSL does it by default (or the SSL_CTX only uses a single
cert), we have to set it with SSL_set_current_cert, yes.
> How about TmpDH used by client (proxy) handshake, is still
> SSL_CERT_SET_SERVER the right cert?
SSL_CTX_set_tmp_dh_callback() - which we use for setting
ssl_callback_TmpDH - applies to a server-mode SSL_CTX only.
> It looks like a regression to me (which may affect several software),
> the callbacks should not care about the loading order of (or previous
> walking though) the certs, and the callback's given SSL current cert
> be the one of the underlying authentication.
I think it boils down to my question from February, in the end ([1],
"Could ssl_lib.c:ssl_get_server_send_pkey be adapted to ensure this?")
Kaspar
[1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201402.mbox/%3C53059D82.3070106@velox.ch%3E