SSL behaviour with multiple server blocks for same port

[Valentin V. Bartenev]

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