Curl "Connection refused" caused by SSL config

Hi all,

I have a strange problem with nginx:
I tried to harden the TLS stack by setting default to recommended values
from https://wiki.mozilla.org/Security/Server_Side_TLS but one server
has to
keep backward compatibility – so I set it up as

http {
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers …
ssl_prefer_server_ciphers on;

server {
listen 443 spdy;
server_name .foo.com bar.foo.com;
}
server {
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers …
ssl_prefer_server_ciphers on;

listen 443 spdy;
server_name foobar.foo.com;
}

}

Problem is that foobar.foo.com starts freezing up randomly after a few
seconds – though sometimes comes back for a short while.
curl from outside reports error as “connection refused”; using curl
localhost:443 responds properly with “* SSL: no alternative certificate
subject name matches target host name ‘localhost’”
CPU usage is not much different from older config; there are no obvious
errors in error_log.

Problem goes away if http-level ssl config is commented out
(ssl_protocols,
especially). I think that indicates this config is not properly parsed
at
the “server” level (does not override http level?)
Seems that I can use the http-level config inside .foo.com server config
without interfering, but I’d like it to be config default instead.

Other notes: 2 nginx hosts in questions are behind a hardware load
balancer

Posted at Nginx Forum:

Also noticed that http-level config causes www.foo.com to show errors on
https://www.200please.com/

Posted at Nginx Forum:

So it looks like the ssl config is valid per-port only. If I set up a
server
on a different port with different ssl config, it works.
Is this a bug or is it by design?

Posted at Nginx Forum:

“Connection refused”, generally means that your server (sometimes this
can
be a firewall too - although firewalls tend to more often just silently
drop
packets) is sending a RST packet to an attempt to connect. Check with
netstat and see if Nginx is bound to your public IP on :443

As for your question on SSL config – it is valid in both the http and
server context, ref.
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols

Your configuration seems to be that you have one certificate, and two
virtual hosts, that respond to different host-headers.

for the first one, you probably mean:

server_name foo.com bar.foo.com;

or do you mean to have it as a catch-all for “*.foo.com”

Are you only trying to enable SSL3 for “foobar.foo.com” and have only
“TLSv1.1 TLSv1.2” for the other one?

Lastly, maybe give some more stuff to work with here, like your actual
URLs,
and your full configuration.

Posted at Nginx Forum:

Thanks Maxim, that explains it
Would be nice if documentation mentioned this fact, or nginx would spit
out
some errors about the conflicting config :wink:

Posted at Nginx Forum:

Hello!

On Thu, Mar 05, 2015 at 09:58:37PM -0500, Fry-kun wrote:

So it looks like the ssl config is valid per-port only. If I set up a server
on a different port with different ssl config, it works.
Is this a bug or is it by design?

This is by design. Before some protocol-specific handshake
happens, it is not possible to tell which virtual server client is
going to request. Therefore, the default server context (and
corresponding options) are used before the handshake.

In this particular case, you are trying to enable SSLv3 for a
virtual server. This is not possible at all even in theory:
there is no SNI extension in SSLv3, and requested virtual server
will be known only after reading an HTTP request. But it won’t be
possible to send an HTTP request as SSLv3 is disabled in the
default server, and therefore the SSL handshake will fail.

See here for some additional details about configuring SSL in
nginx:

http://nginx.org/en/docs/http/configuring_https_servers.html


Maxim D.
http://nginx.org/