On Tue, May 20, 2014 at 11:29:49AM +0200, Remi Gacogne wrote: > > Do you think that openssl only tries to load these DH params from a cert > > when DHE is enabled ? If so, maybe we can register a callback there. > > Unfortunately no, haproxy explicitly tries to load the DH params from a > cert by calling PEM_read_bio_DHparams() in ssl_sock_load_dh_params(), > which is called every time an X.509 server certificate is loaded, except > if OPENSSL_NO_DH is defined.
OK. > > Shouldn't we simply look for "DHE" in the cipher string if that's the way > > people use to declare the algorithms (as a full match, not substring) ? > > We could do that, but then we would rely on the fact that OpenSSL will > always include "DHE" in the text representation of cipher suites using a > DHE key exchange. While I am not a big fan of the OpenSSL bashing > happening these days, I have to admit they have not the best consistency > record, especially regarding the DHE naming, as the OpenSSL source > states in ssl/tls1.h: (...) OK I thought this would have been more consistent than the test you proposed. I not in the best place to criticize people having trouble finding names :-) > So, I am not sure of what to do. Maybe a slightly different warning > message mentioning that DHE might not in use? But I am afraid it may > only confuse users a bit more. Well, maybe your latest patch is still the best way to go then. After all, it's very simple to see what can happen : if ciphers allow DHE and the admin has not configured its param, then there's a risk that some users will run it with too low a parameter and we'd rather warn them. So if the warning is emitted only when preparing an SSL context (and we don't need to emit it more than once), then only possibly affected users will get it, and those not using SSL or not using DHE will not see it. I'm just seeing SSL_CIPHER_description() which returns "DH" optionally followed by a size, maybe it would be a more portable way of checking the presence of DHE in your patch ? Willy
