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

[Thomas Chust]

On Tue, 28 Oct 2014, Florian Zumbiehl wrote:

> [...]
> Regarding specific improvements:
>
> >   [procedure] (ssl-make-client-context* #!key
> >     ((protocol <symbol>) 'tls) ((cipher-list <string|list>) "HIGH")
> >     ((certificate-authorities <string>) #f)
> >     ((certificate-authority-directory <string>) #f)
> >     ((verify? <boolean>) #t))
> >
> >     Creates a new client context. Defaults to TLS protocol using only
> >     ciphers marked as strong. Loads the certificate authorities from the
> >     default directory unless other sources are specified and switches
> >     server certificate verification on by default.
>
> I'm not convinced HIGH is actually a sensible default selection (it
> includes ADH cipher suites, for example), or that cipher limitation is even
> all that important security-wise: If the handshake is not compromised, the
> parties should not ever select anything braindead unless one side
> explicitly prefers that and/or doesn't support anything better.
> [...]

Hello,

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.

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

> [...]
> Selecting ciphers for specific security properties can be sensible, but
> it's difficult to find a generally applicable default that's both highly
> secure and widely compatible.
> [...]

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

> [...]
> As for protocol version selection, it would be a good idea to be able to
> select multiple protocol versions for compatibility with various servers
> that might not all be able to speak the same version, I guess TLS1.0 and
> greater is a reasonable default for the time being. Also, I guess it would
> be good to be able to explicitly select "or higher" so code specifying that
> will automatically support newer TLS versions as they become available.
> [...]

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!

> [...]
> As for certificates, it would be totally great if one could also specify
> the certificate itself directly, without the need to put it into a file,
> just in case you feel like implementing that ... ;-)
> [...]

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.

Ciao,
Thomas


--
When C++ is your hammer, every problem looks like your thumb.