* Joel Sing <[email protected]> [141024 15:59]:
> On Fri, 24 Oct 2014, Bernhard R. Link wrote:
> > Some suggestions for the ressl API:
> >
> > * Please consider making ressl_config_set_protocols accepting a string
> > as option instead.
>
> Already planned - ressl_config_set_protocols() will continue to require a set
> of numeric flags, since it provides a way to be explicit. There will be a
> utility function that takes a protocol string and returns the appropriate
> flag values (or sets the flag values). This will likely allow both
> additive/negative names (e.g. "+tls1.2" or "-sslv3") as well as groups
> (e.g. "compat", "secure", etc).
I'd acclaim an api with just the strings. That ensures that everything
uses it and thus more likely allows me to enable newer protocol versions
in the future[1].
I've run recently into some service that only spoke SSLv3 because
apparently somone wanted to disable older protocols (like SSLv2) and
thus configured using SSLv3 only, which survived many new versions where
it now had the effect of only disabling newer protocols.
It would be nice if there is nice way to say "at least tls1.2"
("-tlsv1.0 -tlsv1.1" feels a bit dangerous: what if soneone extends it
to add support for sslv3 due to popular demand?).
> > * Some way to override the name to be looked for in the certificate
> > would be nice.
> >
> > Both to support speaking with broken/incomplete systems (wrong
> > certificates, certificates not listing alternate interfaces and missing
> > SNI, ..) and for monitoring (connecting to a specific host behind a
> > loadblancer or behind DNS-round-robin and checking the certicate as
> > it will be checked by real clients) a way to specify a different name
> > to expect in the certificate would be nice.
>
> If you call ressl_connect_socket() you already have this functionality via the
> hostname argument. However, it might be worth adding as a configuration
> option for the ressl_connect() case.
>
> > (If using ressl directly one could always use ressl_connect_socket,
> > but I guess most programs using it will only offer calling
> > ressl_config_insecure_noverifyhost (or even only
> > ressl_config_insecure_noverifycert)).
>
> That will not help since ressl_connect_socket() still performs the
> verification checks, unless they are explicitly disabled.
What I mean is:
Imagine some high level program using the ressl library that
for example sends some requests/data via TLS to some type of server. The
author will likely use the simplest interface useable for all the cases
they can imagine (which likely mean ressl_connect and not
ressl_connect_socket) and with some luck offer options to set all the
parameters the library allows to be set (i.e. ressl_config_*).
Now you want to configure the program on some host but the server has a
certificate that does not match its name and is not under your control,
what can you do? Without patching the program (and it would be quite
a big patch, with the need for the whole socket code where currently
is only a call to ressl_connect), all you can do is instruct it to
not check the hostname in the certificate at all.
> > * An option to only look at subjectAltName and not CN would be nice.
> >
> > If only to allow more paranoid monitoring checking if ssl clients
> > not looking at CN can connect (or not looking at CN if there is
> > subjectAltName).
>
> This one seems a little strange. If you can specify a hostname for validation,
> it is either in the CN, the SAN or both. I'm not sure that not matching the
> CN makes sense in that case. Is there a use case that I'm missing?
RFC 6152 suggests to no longer look at CN-ID, but only at SAN.
I've not yet seen any client doing this (and doing this by default will
likely break a lot of things), but it would be nice if one could
configure clients to behave this way to ensure everything still works
then.
Bernhard R. Link
[1] It's quite frustating to have a new openssl library available on the
host but not able to use the newer protocols because python-ssl < 3.4
does not allow it.
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
