Re: hardcoded ssloptions
On Wed, Oct 29, 2014 at 02:29:21PM -0700, Bryan Talbot wrote: I think he wants to globally disable SSLv3 (by removing support at compile time) so it can't be accidentally enabled in an errant bind option. There's no way to disable SSLv3 globally in the haproxy config. Then probably we should have a flag for this in the global section, just like we have settings for dh-params or verify-none. Willy
Re: hardcoded ssloptions
On Wed, Oct 29, 2014 at 08:24:31PM +0100, Lukas Tribus wrote: Previous mail was somehow messed up, here is my proper response: is there any sensible reason that value of ssloptions is hardcoded instead of passed with config (ie. similiary to ssl-default-bind-ciphers)? i'd like to add NO_SSLv3 which is apparently not in 1.5.6 and in future it may be likely to add some other options to avoid openssl bugs in production... I'm not sure I understand what you mean. You can disable SSLv3 among other things just fine in haproxy 1.5: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#no-sslv3%20%28Bind%20options%29 sorry, for not being clear. i'd like this: src/ssl_sock.c: 1469 long ssloptions = 1470 SSL_OP_ALL | /* all known workarounds for bugs */ 1471 SSL_OP_NO_SSLv2 | 1472 SSL_OP_NO_COMPRESSION | 1473 SSL_OP_SINGLE_DH_USE | 1474 SSL_OP_SINGLE_ECDH_USE | 1475 SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION | 1476 SSL_OP_CIPHER_SERVER_PREFERENCE; to be configurable. main reasoning: all known workarounds for bugs as of compile time might change in future (as new openssl bugs are being uncovered). and concerning SSL_OP_NO_SSLv3 versus disabling on protocol level - from what ssllabs handshake simulation is giving me, i think this option also disables DH = 1024 bits kex. -- konrad rzentarzewski -- System Administrator, Efigence S.A. Office: +48.223801313 Off-hours: +48.222961020 EFI42-RIPE
RE: hardcoded ssloptions
Hi, You can disable SSLv3 among other things just fine in haproxy 1.5: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#no-sslv3%20%28Bind%20options%29 sorry, for not being clear. i'd like this: src/ssl_sock.c: 1469 long ssloptions = 1470 SSL_OP_ALL | /* all known workarounds for bugs */ 1471 SSL_OP_NO_SSLv2 | 1472 SSL_OP_NO_COMPRESSION | 1473 SSL_OP_SINGLE_DH_USE | 1474 SSL_OP_SINGLE_ECDH_USE | 1475 SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION | 1476 SSL_OP_CIPHER_SERVER_PREFERENCE; to be configurable. main reasoning: all known workarounds for bugs as of compile time might change in future (as new openssl bugs are being uncovered). I still don't get it. These are not openssl bugs, but workarounds in openssl for bugs in other ssl libraries or applications. Lets assume newer openssl releases introduce a new workaround. SSL_OP_ALL will enable that workaround, so we should be good. SSL_OP_ALL is a safe setting that the application is supposed to set. I strongly disagree that we should make every single OpenSSL option configurable, this will just mess-up documentation and configuration and will more often than not be miss-configured by the users. I don't think any application lets you configure single openssl workarounds or can you name one? and concerning SSL_OP_NO_SSLv3 versus disabling on protocol level Whats the difference between using SSL_OP_NO_SSLV3 and disabling it on protocol level exactly? what ssllabs handshake simulation is giving me, i think this option also disables DH = 1024 bits kex. Which I assume is perfectly expected because by disabling SSLv3 you also disable ciphers unsupported in TLSv1. Regards, Lukas
RE: hardcoded ssloptions
main reasoning: all known workarounds for bugs as of compile time might change in future (as new openssl bugs are being uncovered). I still don't get it. These are not openssl bugs, but workarounds in openssl for bugs in other ssl libraries or applications. not in all cases, some options are security-related and server-side (ie. CIPHER_SERVER_PREFERENCE, NO_SESSION_RESUMPTION_ON_RENEGOTIATION, SINGLE_DH_USE). Right, and we can evaluate on a case-by-case basis whether it makes sense to introduce a new a configuration knob for a single option. Unconditionally introducing all of them is completely unnecessary however. Lets assume newer openssl releases introduce a new workaround. SSL_OP_ALL will enable that workaround, so we should be good. SSL_OP_ALL is a safe setting that the application is supposed to set. SSL_OP_ALL doesn't apply all SSL_OPs, see /usr/include/openssl/ssl.h Which is a good thing. We can introduce new options as configuration knobs if and when we need them, after all, we can't predict what options openssl will support in future, don't we? I strongly disagree that we should make every single OpenSSL option configurable, this will just mess-up documentation and configuration and will more often than not be miss-configured by the users. I don't think any application lets you configure single openssl workarounds or can you name one? i already did: stunnel. I meant without hacking the source-code, of course. i don't really know wheter it's big advantage to have it configurable at this time, probably not, as current hardcoded ssloptions value is safe. i know that we needed to add some opts in july to stunnel, as they were not default for openssl at that time to prevent BEAST and friends. Beast mitigation just needs 2 things: server side cipher selection and a specific cipher list. No problem in haproxy. besides, it's exactly the same with the ciphers - you don't need to include them all in documentation (it's perfectly sufficient to refer to openssl documentation) and i believe it's being used by most users, as defaults are not most secure... You are comparing two completely different things. For every single SSL option we need to patch the source code and document the configuration knob, while the cipher-list is just passed to openssl. and concerning SSL_OP_NO_SSLv3 versus disabling on protocol level Whats the difference between using SSL_OP_NO_SSLV3 and disabling it on protocol level exactly? what ssllabs handshake simulation is giving me, i think this option also disables DH = 1024 bits kex. Which I assume is perfectly expected because by disabling SSLv3 you also disable ciphers unsupported in TLSv1. it doesn't seem to be true for all cases. with SSL_OP_NO_SSLV3 ssllabs claims handshake failure for jdk6. wihout it, it connects with 1024 DH. all with sslv3 proto disabled. Its a bit more complex than that and you would have to provide a lot more informations if you would like to know the reason for this behavior, but I would suspect your cipher configuration is to blame here. Lukas
Re: hardcoded ssloptions
On 10/30/2014 04:19 PM, konrad rzentarzewski wrote: On Thu, Oct 30, 2014 at 02:25:01PM +0100, Lukas Tribus wrote: main reasoning: all known workarounds for bugs as of compile time might change in future (as new openssl bugs are being uncovered). I still don't get it. These are not openssl bugs, but workarounds in openssl for bugs in other ssl libraries or applications. not in all cases, some options are security-related and server-side (ie. CIPHER_SERVER_PREFERENCE, NO_SESSION_RESUMPTION_ON_RENEGOTIATION, SINGLE_DH_USE). Lets assume newer openssl releases introduce a new workaround. SSL_OP_ALL will enable that workaround, so we should be good. SSL_OP_ALL is a safe setting that the application is supposed to set. SSL_OP_ALL doesn't apply all SSL_OPs, see /usr/include/openssl/ssl.h I strongly disagree that we should make every single OpenSSL option configurable, this will just mess-up documentation and configuration and will more often than not be miss-configured by the users. I don't think any application lets you configure single openssl workarounds or can you name one? i already did: stunnel. i don't really know wheter it's big advantage to have it configurable at this time, probably not, as current hardcoded ssloptions value is safe. i know that we needed to add some opts in july to stunnel, as they were not default for openssl at that time to prevent BEAST and friends. Do you know other projects than stunnel where this stuff is done? I've just checked for nginx and apache still use hardcoded values. I used them as references (with also 'stud') when i code the ssl layer stuff in HAproxy. I think these projects (with haproxy) represent the biggest part of professional usages. So i'm surprised they never faced this kind of need. R, Emeric
Re: hardcoded ssloptions
[ asymmetric hello ] On Thu, Oct 30, 2014 at 04:19:34PM +0100, konrad rzentarzewski wrote: i already did: stunnel. And does it have any real use in the end ? In haproxy we have also done totally pointless things that nobody has ever found a use for as well, and we better try to forget them instead of promoting them (hint: try to declare a ruleset section). i don't really know wheter it's big advantage to have it configurable at this time, probably not, as current hardcoded ssloptions value is safe. i know that we needed to add some opts in july to stunnel, as they were not default for openssl at that time to prevent BEAST and friends. besides, it's exactly the same with the ciphers - you don't need to include them all in documentation (it's perfectly sufficient to refer to openssl documentation) and i believe it's being used by most users, as defaults are not most secure... I totally disagree, it would even be the opposite. Let's suppose for a minute that we provide an option which lets you force every single bit of ssloptions. For example you have the following in the global section : global ssl.force-options 0x1234 # workaround the ZORGLUB attack What will happen then ? You'll find this config posted on every blog and people will start to copy-paste it into their configuration without realizing that it is only relevant to a certain exact version of openssl, not knowing that their version of the library does not necessarily implement the extra flags and silently ignores them. In the end you get some users who *believe* they're safe while they're absolutely not. At least having to upgrade one component (haproxy/openssl/whatever) is a good way to know if you're safe or vulnerable. So I'd rather suggest that we *do not* implement something which makes users feel safe when they are not. Willy
RE: hardcoded ssloptions
is there any sensible reason that value of ssloptions is hardcoded instead of passed with config (ie. similiary to ssl-default-bind-ciphers)? i'd like to add NO_SSLv3 which is apparently not in 1.5.6 and in future it may be likely to add some other options to avoid openssl bugs in production... I'm not sure I understand what you mean. You can disable SSLv3 among other things just fine in haproxy 1.5: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#no-sslv3%20%28Bind%20options%29 Lukas
RE: hardcoded ssloptions
Previous mail was somehow messed up, here is my proper response: is there any sensible reason that value of ssloptions is hardcoded instead of passed with config (ie. similiary to ssl-default-bind-ciphers)? i'd like to add NO_SSLv3 which is apparently not in 1.5.6 and in future it may be likely to add some other options to avoid openssl bugs in production... I'm not sure I understand what you mean. You can disable SSLv3 among other things just fine in haproxy 1.5: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#no-sslv3%20%28Bind%20options%29 Lukas
Re: hardcoded ssloptions
I think he wants to globally disable SSLv3 (by removing support at compile time) so it can't be accidentally enabled in an errant bind option. There's no way to disable SSLv3 globally in the haproxy config. -Bryan On Wed, Oct 29, 2014 at 12:24 PM, Lukas Tribus luky...@hotmail.com wrote: Previous mail was somehow messed up, here is my proper response: is there any sensible reason that value of ssloptions is hardcoded instead of passed with config (ie. similiary to ssl-default-bind-ciphers)? i'd like to add NO_SSLv3 which is apparently not in 1.5.6 and in future it may be likely to add some other options to avoid openssl bugs in production... I'm not sure I understand what you mean. You can disable SSLv3 among other things just fine in haproxy 1.5: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#no-sslv3%20%28Bind%20options%29 Lukas
