>>> 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
