Re: [Chicken-users] OpenSSL egg option defaults poll

[Florian Zumbiehl]

Hi,

> well, if I understand some of the problems with SSL/TLS in the past
> years correctly, the fact that a specifically engineered client
> could force a brain-dead cipher suite selection actually posed a
> problem several times.

I am not sure I understand what you mean--you never can protect against a
client that doesn't want to protect the session, they always could just
publish the session key, or the decrypted data, or whatever. The protection
should always focus on third parties that try to undermine the security.

> But you are certainly right about the non-authenticated schemes,
> maybe setting the default to "HIGH:!aNULL" makes more sense?

More sense, yeah. I would still just go with the default.

> I think the idea here is to set some defaults that are reasonably
> secure, even if that means less compatible. If you want to transmit
> top-secret data you will need something entirely different from
> SSL/TLS, anyway; and if you don't care about security you can use
> the old API ;-)

I don't see any serious security problems with the default. If the
configuration of the peer isn't braindead, that will negotiate a reasonably
secure cipher suite, the default connected to itself will negotiate
ECDHE-RSA-AES256-GCM-SHA384 (if the necessary server-side initialization
for ECDHE cipher suites has been done), plus you could argue that RC4 is
actually still more secure than CBC modes with TLS < 1.1 due to BEAST,
unless both sides implement 1/n-1 splitting or the application protocol can
not be used to perform the attack.

I guess my point is: TLS is pretty fragile if you need any compatibility at
all, there are lots more things to consider besides cipher suite selection,
and there isn't even a globally valid preference order of cipher suites,
what's good for TLS 1.2 is not necessarily for TLS 1.0, what's good on
desktop machines with constant-time AES is not necessarily good on mobile
devices without, ...

> I agree, however the only easy to use presets in the OpenSSL library
> are SSLv2, SSLv3, TLS or any of them selected automatically. The
> latter has been the default so far, but that means the vulnerable
> SSLv3 can be selected, too. Judging by the documentation I'm not
> even sure whether TLS means TLS 1.0 or TLS in any supported version.
> 
> It would be great if someone who really groks the OpenSSL API could
> help out here!

I don't think anyone groks the OpenSSL API ;-), but as far as I could tell,
roughly this should do the right thing (well, it's obviously taken from a
server, but the principle should be applicable in the general case):

| SSL_CTX *sslctx;
| long ssl_set_options;
| const SSL_METHOD *ssl_method;
| 
| ssl_set_options=0;
| switch((SSL_VERSIONS)){
|       case SSL_V3:
|               ssl_method=SSLv3_server_method();
|               break;
|       case TLS_V10:
|               ssl_method=TLSv1_server_method();
|               break;
|       case TLS_V11:
|               ssl_method=TLSv1_1_server_method();
|               break;
|       case TLS_V12:
|               ssl_method=TLSv1_2_server_method();
|               break;
|       default:
|               ssl_method=SSLv23_server_method();
|               ssl_set_options|=SSL_OP_NO_SSLv2;
|               if(!((SSL_VERSIONS)&SSL_V3))ssl_set_options|=SSL_OP_NO_SSLv3;
|               if(!((SSL_VERSIONS)&TLS_V10))ssl_set_options|=SSL_OP_NO_TLSv1;
|               if(!((SSL_VERSIONS)&TLS_V11))ssl_set_options|=SSL_OP_NO_TLSv1_1;
|               if(!((SSL_VERSIONS)&TLS_V12))ssl_set_options|=SSL_OP_NO_TLSv1_2;
| }
| if(!(sslctx=SSL_CTX_new(ssl_method)))die(false,"SSL_CTX_new()");
| 
if((SSL_CTX_set_options(sslctx,ssl_set_options)&ssl_set_options)!=ssl_set_options)die(false,"SSL_CTX_set_options()");

> Hmm, I remember that was somehow difficult back when I first
> implemented the old API. I don't recall the reason and I'll just
> look into it again.

Yeah, I think you need memory BIOs and stuff, certainly not trivial ;-)

Florian