Different SSL protocols for different server blocks on the same port
Maxim Dounin
mdounin at mdounin.ru
Tue Apr 28 14:24:30 UTC 2015
Hello!
On Tue, Apr 28, 2015 at 02:00:07PM +0000, Aviram Cohen wrote:
> Hello!
>
> The Nginx configuration allows you to define different server
> blocks that have different server names but listen on the same
> port in SSL. For an incoming connection, Nginx uses SNI in order
> to know under which server block the connection should be
> handled.
> However, the 'ssl_protocols' directive doesn't work as expected
> in this scenario.
> Let's say that we have two servers blocks - the first allows
> TLSv1, TLSv1.1 and TLSv1.2, and the second allows only TLSv1
> connections ('ssl_protocols TLSv1;' directive). From what I've
> seen, in this case, the second server will still accept incoming
> TLSv1.1 and TLSv1.2 connections.
>
> I've debugged it a bit, and wrote some independent code that
> uses OpenSSL, and it seems that OpenSSL doesn't allow you to
> change the supported TLS versions of a connection during the SNI
> callback.
> The following may occur - an incoming connection to the second
> server starts, and it gets the default SSL CTX object (in Nginx,
> that would be the context of the first server block). When the
> SNI callback (ngx_http_ssl_servername) is called, the context is
> replaced for the connection (with the context of the second
> server block), along with the SSL options of the connections
> (SSL_set_options is called with the new CTX's options). These
> options contain the second server's allowed protocols. Even
> though the correct options are set, when the handshake
> continues, it would succeed even for TLSv1.1 and TLSv1.2 (which
> are enabled for the first server, but not for the second one).
>
> A similar problem can occur as well; for example, if the first
> server allows only for TLSv1 connections and the second one
> allows for TLSv1.1, then TLSv1.1 connections will be rejected by
> OpenSSL, even if their SNI name is the name of the second
> server.
>
> This seems like an OpenSSL issue (I've reproduced it on both
> v1.0.1 and v1.0.2), but I think that this should at least be
> documented in Nginx's SSL documentation, as the 'ssl_protocols'
> directive doesn't behave as expected for different server blocks
> with the same port - you'd expect that one server block would
> not affect the other, but it does.
>
> Nginx development team (e.g. Maxim, Igor), I'd love to hear your
> thoughts about this.
> Below is an example of this scenario.
This was discussed a while ago, see here and previous messages:
http://mailman.nginx.org/pipermail/nginx/2014-November/045738.html
In short: there are some cases which should work IMHO, but don't
due to OpenSSL behaviour. There are other cases which aren't
expected to work at all, even theorethically.
I don't think that OpenSSL behaviour here is a bug - the SNI
callback can only happen once OpenSSL started processing of a
ClientHello message, and it basically means that it already chosen
a protocol to use. While in theory it can be possible to choose
another protocol - it will seriously complicate things.
I also think that people trying to do such things with SNI
are utterly wrong.
--
Maxim Dounin
http://nginx.org/
More information about the nginx-devel
mailing list