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
