SSL behaviour with multiple server blocks for same port

Valentin V. Bartenev vbart at nginx.com
Mon Feb 3 18:01:12 UTC 2014


On Thursday 23 January 2014 15:54:58 Alex wrote:
> > On Thu, Jan 23, 2014 at 11:17:42AM +0000, Pankaj Mehta wrote:
> 
> Hi,
> 
> > These blocks have different ssl certificates. I understand that if I enable
> > SNI in nginx and the client supports it, then we have a predictable
> > behaviour where nginx will use the correct ssl parameters from the server
> > block corresponding to that hostname. But I have no idea which ssl config
> 
> One thing I became painfully aware of last time is that when you use
> SSL-enabled server blocks with SNI, a listen directive from one block
> may overwrite the listen directive from another one.
> 
> For example, when I have:
> 
> server {
> 	listen 443 ssl;
> 	server_name www.host1.com;
> 
> 	...
> }
> 
> and 
> 
> server {
> 	listen 443 ssl spdy;
> 	server_name www.host2.com;
> 
> 	...
> }
> 
> Even though the listen directive for server block of www.host1.com does
> not define SPDY, it accepts SPDY connections as well. In other words, if
> you want to disable SPDY, you'd have to make sure that it doesn't appear
> in any server block listen directive (assuming you're using SNI rather
> than dedicated IPs).
> 
> I am not sure if this behavior can be avoided. nginx advertises spdy/2
> via the NPN TLS extension. During the TLS handshake, would it be
> possible to first parse the hostname the client is attempting to connect
> (SNI), and only then decide whether to advertise SPDY via NPN or not
> depending on the hostname's listen directive?
> 

Sorry for the late answer.

This behavior cannot be avoided since even if you do not advertise SPDY via 
NPN/ALPN for some virtual hosts, but do for another, then browsers still be 
able to request any of them using an already established SPDY connection.

  wbr, Valentin V. Bartenev



More information about the nginx mailing list