Just an update: as of today, even Debian provides
libssl1.0.0:1.0.1e-2+deb7u16 which still generates these error logs, so
it
looks like the only way is still to fallback to
libssl1.0.0:1.0.1e-2+deb7u12.
Posted at Nginx Forum:
I found myself with the same problem and found the cause (and obvious
solution).
On my nginx server I run various website and they all have their own
server
{} config block in separate files under ‘sites-available’ folder.
Some sites are on different IP’s and some are on the same IP.
Now the cause of the problem was because I’d had set 2 server blocks
listening on the same IP on SSL for different server_names like so:
server {
listen 37.230.101.215:443 ssl spdy;
server_name www.domain1.com *.domain1.com;
ssl on;
ssl_certificate /etc/ssl/cert.crt;
ssl_certificate_key /etc/ssl/key.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
…etc
}
and for another site the same:
server {
listen 37.230.101.215:443 ssl spdy;
server_name www.domain2.com *.domain2.com;
ssl on;
ssl_certificate /etc/ssl/cert.crt;
ssl_certificate_key /etc/ssl/key.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
…etc
}
When you do this it gives the exact same error as this thread is about…
might be something to check.
Posted at Nginx Forum:
Out of thin air, I suspect it is a certificate problem.
You seem to have configured the same certificate (and private key) for
those 2 domains. Since certificates are generally tied to a single
domain,
that could explain errors.
Another idea: have you checked nginx has been built with SNI support and
you client also supports it? Problems with SNI would mean the default
server certificate (since you did not define a default server for your
IP
address/port pair, nginx would pick up the first block containing a
‘listen’ directive configured for it) would be presented whatever domain
you are trying to access, ending up with certificate/domain mismatch.
See Configuring HTTPS servers.
B. R.
Here’s what we’ve learned so far:
The issue is related to a new security feature that blocks TLS Fallback,
which is a client that connects with one version of TLS, then tries to
downgrade the connection and connect with a lower TLS version… It was a
feature made in light of the Poodle SSL vulnerability in order to keep
SSL
secure. The problem is that many networking libraries still exhibit this
behavior of downgrading TLS versions on purpose, which OpenSSL then
blocks
the connection.
Specificially, the NSURLConnection class on iOS exhibits this behavior.
NSURLSession, the latest iteration of this client, does not. The problem
is,
if you want to support iOS 6 still, you HAVE to use NSURLConnection. We
decided to end support for iOS 6 because of this. NSURLConnection is
also
completely depracated in iOS 9, so if you want to support iOS 9, you’ll
have
to upgrade your client library anyway.
On Android, the same thing happened, but not as often and between
different
TLS versions. Switching to Square’s Retrofit client for SSL purposes has
worked really well for us.
So, the real fix is to make sure you update your clients. If you’re on a
Debian wheezy box, you can make your own openssl package with the latest
version, but with TLS_FALLBACK_SCSV support removed by following the
directions below. Note, this is not recommended from a security
perspective,
but if your environment is broken, you need to do what you need to do.
As
long as SSL v3 is disabled, there’s no big, active vulnerability in the
wild
that takes advantage of fallback at the moment.
Setup dquilt as shown on
https://www.debian.org/doc/manuals/maint-guide/modify.en.html
Building Package:
apt-get update ; apt-get source libssl1.0.0
cd openssl-1.0.1e
dquilt pop Support-TLS_FALLBACK_SCSV
dquilt delete Support-TLS_FALLBACK_SCSV
dpkg-source --commit
dpkg-buildpackage
The debian packages will be one directory back. Make sure to install the
libssl packages you created, not just openssl, and nginx will need a
restart
to use the new library, not just a reload.
I hope this helps someone, we spent a good amount of time on this.
Posted at Nginx Forum:
Hello!
On Tue, Jul 14, 2015 at 09:58:52PM -0400, tempspace wrote:
Specificially, the NSURLConnection class on iOS exhibits this behavior.
So, the real fix is to make sure you update your clients. If you’re on a
Building Package:I hope this helps someone, we spent a good amount of time on this.
Thanks for the info, appreciated.
–
Maxim D.
http://nginx.org/
Yeah I removed the double blocks and it solved the problem…
The ‘possible bug’ though is that the problem seems completely random…
instead of giving error all the time sometimes it works and sometimes it
doesn’t… Just refreshing the site a few times and it worked…
So it looks like Nginx just randomly picks the cert…
Also SNI is enabled I checked.
B.R. Wrote:
server certificate (since you did not define a default server for your
IP
address/port pair, nginx would pick up the first block containing a
‘listen’ directive configured for it) would be presented whatever
domain
you are trying to access, ending up with certificate/domain mismatch.
See Configuring HTTPS servers.B. R.
Posted at Nginx Forum:
I am facing the same issue on my Debian 7 Server. I downgraded to
1.0.1e-2+deb7u12 version of libssl1.0.0 and restarted nginx but the
issue is
still occurring for me. I can still see the same logs.
I also tried following these instructions(installed the deb packages
made by
these instructions) but even these didn’t help:
apt-get update ; apt-get source libssl1.0.0
cd openssl-1.0.1e
dquilt pop Support-TLS_FALLBACK_SCSV
dquilt delete Support-TLS_FALLBACK_SCSV
dpkg-source --commit
dpkg-buildpackage
Can anybody suggest as to what i can do to fix this?
After trying both methods, i restarted nginx by using
sudo service nginx restart
But i can still see the same error logs.
How can i be sure that nginx is picking up the updated libssl and
openssl
binaries? Is there any way to check if the SSL library which NGINX is
using
has support for TLS_FALLBACK_SCSV?
Posted at Nginx Forum:
I am facing the same problem. I had one ssl certificate setup for the
following domains:
firstdomain.com
*.firstdomain.com
a.firstdomain.com
b.firstdomain.com
a.seconddomain.com
b.seconddomain.com
When i read that it could be due to multiple different domains using the
same ssl certificate, i removed the seconddomain.com server blocks from
my
nginx. So now i am left with:
firstdomain.com
*.firstdomain.com
a.firstdomain.com
b.firstdomain.com
The error frequency seems to have gone down but i still see some errors.
How
do you suggest i solve it?
I can try and merge a.firstdomain.com and b.subdomain.com so that they
can
be accessed from the same server block *.firstdomain.com
Then only 2 server blocks will be left:
firstdomain.com
*.firstdomain.com
Do you think i’ll still face the same issue after this? If yes, should i
move firstdomain.com to a different server?
If no, how do you suggest i try to solve this?
It would be great if you can help me solve this. Thanks.
Posted at Nginx Forum:
do want to add the cert I was using was subdomain wildcard and the
blocks
where for different subdomains so that should not have been a problem
with
the cert… maybe its an access issue to the cert? (nginx can’t access it
multiple times at the same moment or something)
Posted at Nginx Forum: