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

[Florian Zumbiehl]

Hi,

> Therefore I took another route: The existing procedures keep their
> current defaults, but there is a new set of object constructors that
> uses only keyword arguments and configures things in a more secure
> way by default.

That seems sensible to me, in particular as making existing APIs behave in
backward incompatible ways tends to be ugly.

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.

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. If you control both sides, you might want to
use only ciphers with forward secrecy and without MAC-then-encrypt (to
avoid padding oracles), for example, but if you make that the default for
the egg, you'll find many servers out there that won't know how to talk to
you.

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.

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

Verifying certificates by default is a very good idea indeed.

Also, there are a few more things that are advisable to do for secure TLS,
some of which (those that apply to the client side) are addressed by the
patches that are currently blocked by andyjpb's fix, such as disabling TLS
compression and requiring support for secure renegotiation from the server
(though the latter may not be supported widely enough yet to make it the
default, I'm not sure). On the server side, to make forward secrecy
actually work, you have to set up callbacks that supply DH parameters and
stuff, it's pretty ugly, but I may be able to supply code snippets if you
are interested.

Florian