RE: RFC: Statically enable SSL_OP_SINGLE_DH_USE
>> I don't see it. Can you please elaborate what exact commit ID your are >> refering to? > > You are probably refering to the github fork, which is as always outdated, > and where line 2539 points to the local definition of SSL_OP_SINGLE_DH_USE: > #ifndef SSL_OP_SINGLE_ECDH_USE > #define SSL_OP_SINGLE_ECDH_USE 0 > #endif Actually I mixed up SSL_OP_SINGLE_DH_USE with SSL_OP_SINGLE_ECDH_USE, but the point is still the same. Lukas
Re: RFC: Statically enable SSL_OP_SINGLE_DH_USE
Hi Lukas, Lukas Tribus wrote: >>> I don't see it. Can you please elaborate what exact commit ID your are >>> refering to? >> You are probably refering to the github fork, which is as always outdated, >> and where line 2539 points to the local definition of SSL_OP_SINGLE_DH_USE: >> #ifndef SSL_OP_SINGLE_ECDH_USE >> #define SSL_OP_SINGLE_ECDH_USE 0 >> #endif > > Actually I mixed up SSL_OP_SINGLE_DH_USE with SSL_OP_SINGLE_ECDH_USE, but > the point is still the same. Ah, now it becomes clear. The #defines are just to set defaults if the constant isn't defined at all. Normally, the constant is defined by OpenSSL itself. As HAProxy sets it in [1], everything should be fine. Sorry for the noise from someone who reads way too little C code... Regards, Holger [1] http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/src/ssl_sock.c;h=5cec6a4cd6ce5d16f9564e60fa57b24c46112bac;hb=HEAD#l2560
Re: RFC: Statically enable SSL_OP_SINGLE_DH_USE
Hi Lukas, Lukas Tribus wrote: > I don't see it. Can you please elaborate what exact commit ID your are > refering to? I was looking at http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/src/ssl_sock.c;h=5cec6a4cd6ce5d16f9564e60fa57b24c46112bac;hb=HEAD#l2539 > As far as I an see we do the exact opossite of what you are saying > (enabling SSL_OP_SINGLE_DH_USE unconditionally). Sorry, it might well be that I'm too unfamiliar with the way these flags work. I assumed that setting it to 0 disabled the flag. If this is actually not the case, that I hereby retract by request and resolve to read more about how this is intended to work... Regards, Holger
RE: RFC: Statically enable SSL_OP_SINGLE_DH_USE
>> In HAProxy, this flag is currently statically disabled by default in >> src/ssl_sock.c line 2539. Thus, when used with older OpenSSL versions >> than 1.0.1r or 1.0.2f, users could be vulnerable. > > I don't see it. Can you please elaborate what exact commit ID your are > refering to? You are probably refering to the github fork, which is as always outdated, and where line 2539 points to the local definition of SSL_OP_SINGLE_DH_USE: #ifndef SSL_OP_SINGLE_ECDH_USE #define SSL_OP_SINGLE_ECDH_USE 0 #endif You are misunderstanding this code. We define SSL_OP_SINGLE_ECDH_USE when the openssl headers don't define it (which is when the openssl release doesn't support SSL_OP_SINGLE_ECDH_USE - older than 1.0.0), to avoid #ifdef hell in the ssl_sock_prepare_ctx function. So when OpenSSL supports SSL_OP_SINGLE_ECDH_USE, we *do* set it. Lukas
RE: RFC: Statically enable SSL_OP_SINGLE_DH_USE
> In HAProxy, this flag is currently statically disabled by default in > src/ssl_sock.c line 2539. Thus, when used with older OpenSSL versions > than 1.0.1r or 1.0.2f, users could be vulnerable. I don't see it. Can you please elaborate what exact commit ID your are refering to? As far as I an see we do the exact opossite of what you are saying (enabling SSL_OP_SINGLE_DH_USE unconditionally). Lukas
RFC: Statically enable SSL_OP_SINGLE_DH_USE
Hi there, following CVE-2016-0701, the OpenSSL project switched the behavior of the SSL_OP_SINGLE_DH_USE flag to a no-op and forcefully enabled the feature. This results in OpenSSL always generating a new DH parameters for each handshake which can protect the private DH exponent from certain attacks. In HAProxy, this flag is currently statically disabled by default in src/ssl_sock.c line 2539. Thus, when used with older OpenSSL versions than 1.0.1r or 1.0.2f, users could be vulnerable. I propose to enable this flag in HAProxy to be safe with older OpenSSL versions, e.g. when users are unable to update their OpenSSL library due to system constraints. On current OpenSSL versions, this switch is a no-op anyway. Regards, Holger PS: I'm not too familiar with actually working with OpenSSL itself or its various pitfalls. Thus, it is probably a good idea for someone more familiar with OpenSSL to have a critical look at this request. References: * OpenSSL Security Advisory: http://openssl.org/news/secadv/20160128.txt * Fix in OpenSSL 1.0.1: https://github.com/openssl/openssl/commit/8bc643efc89cbcfba17369801cf4eeca037b6cc1 * Fix in OpenSSL master: https://github.com/openssl/openssl/commit/ffaef3f1526ed87a46f82fa4924d5b08f2a2e631
