SSL behaviour with multiple server blocks for same port

Hi,

I am struggling to get any documented reference for my problem in nginx
docs. Hope someone can help before I delve into nginx code:

I want to have multiple server blocks for the https port 443, they will
serve different hostnames. Each block will have it’s own ssl
configuration.
For example:

server {
listen 443 ssl
server_name blah.xyz.com

ssl protocols TLSv1
ssl_ciphers AES256-SHA:RC4-SHA;
ssl_certificate /test/site1.cer;
ssl_certificate_key /test/site1.key;

}

server {
listen 443 ssl
server_name blah.xyz.com

ssl protocols TLSv1
ssl_ciphers AES256-SHA:RC4-SHA;
ssl_certificate /test/site2.cer;
ssl_certificate_key /test/site2.key;

}

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
will be picked up when the client does not support SNI. Is it the one
that
comes first? Also is the behaviour when SNI is disabled in nginx similar
to
when SNI is enabled in nginx but client doesn’t support it?

Is there a way in nginx to dump the active configs for a port?

Thanks
Pankaj

Hello!

On Thu, Jan 23, 2014 at 11:17:42AM +0000, Pankaj Mehta wrote:

listen 443 ssl
listen 443 ssl
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
will be picked up when the client does not support SNI. Is it the one that
comes first?

http://nginx.org/r/listen

Quote:

The default_server parameter, if present, will cause the server to
become the default server for the specified address:port pair. If
none of the directives have the default_server parameter then the
first server with the address:port pair will be the default server
for this pair.

Also is the behaviour when SNI is disabled in nginx similar to
when SNI is enabled in nginx but client doesn’t support it?

Yes.

Is there a way in nginx to dump the active configs for a port?

No.


Maxim D.
http://nginx.org/

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?

Alex

On Thursday 23 January 2014 15:54:58 Alex wrote:

SSL-enabled server blocks with SNI, a listen directive from one block

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

On 2014-02-03 19:01, Valentin V. Bartenev wrote:

Sorry for the late answer.

Hi! No problem at all!

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.

That makes sense - thanks for the explanation. I guess it’d be easier in
cases like these if nginx had some functionality to display the values
of currently parsed config parameters (similar to postconf in postfix),
which would allow to quickly detect possibly unwanted configurations
(such as the SPDY parameter that was still present in certain NPN-based
vhosts) and/or configurations that deviate from standard settings. Not
that it’s important… just in case we run out of ideas how to improve
nginx further. :wink:

Thanks Maxim, very helpful.

Pankaj

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs