From the docs:
Syntax: ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2];
Default:
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
Context: http, server
however I’m trying to have onde server with:
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
and another with:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
But the first seems to be applied to all.
Note that the certs are different echo server is for a diferent domain (
example.org and example2.org)
Is this the intended behaviour? we want to disable sslv3 for the main
domain but still need backward compatibility support in some stuff
running
in the old one!
Thanks
nginx mailing list
removed_email_address@domain.invalid
http://mailman.nginx.org/mailman/listinfo/nginx
On Thu, Oct 16, 2014 at 12:01:13AM +0100, Miguel C. wrote:
Hi there,
I do not know the answer, but…
however I’m trying to have onde server with:
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
and another with:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
But the first seems to be applied to all.
what configuration method do you use to have two different ssl-enabled
servers running in one nginx?
http://nginx.org/en/docs/http/configuring_https_servers.html#name_based_https_servers
The answer to that may eliminate some possibilities from the answer to
your question.
f
Francis D. removed_email_address@domain.invalid
could youe please send/gist your (anonymized) server {} configs?
one suggestions: enable 2 different access-logs for each server-black
and
confirm requests to dom1.com go to the configured dom1.com and
requests to dom2.com go to the configured dom2.com.
once you are sure the requests go to the right server {} - config
we can try to figure out whats happening.
cheers,
mex
Posted at Nginx Forum:
listen 443 ssl spdy;
Actually but sni is working fine sslabs reports the correct certs…
just
tells me SSLv3 is on in all when its only set for one of the domains…
At first I had " ssl_protocols TLSv1 TLSv1.1 TLSv1.2;" at the http level
and just set " ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; " in one of
the
servers/domain I removed that for http block and now have the different
“ssl_protocols” directive in the corresponding configs and sslabs
reports
the one defined in the first.
If I change the order (sslv3 first) sslabs reports all servers/domains
have
sslv3 on but curl fails with “-sslv3” and the error is related to the
cert
name … but I’m assuming that’s just because sni is a TLS extension
not
SSL… so it actually proves sslv3 is on when it shouldn’t be!
nginx mailing list
removed_email_address@domain.invalid
http://mailman.nginx.org/mailman/listinfo/nginx
nginx mailing list
removed_email_address@domain.invalid
http://mailman.nginx.org/mailman/listinfo/nginx
Hello!
On Thu, Oct 16, 2014 at 12:37:19AM +0100, Miguel C. wrote:
If I change the order (sslv3 first) sslabs reports all servers/domains have
sslv3 on but curl fails with “-sslv3” and the error is related to the cert
name … but I’m assuming that’s just because sni is a TLS extension not
SSL… so it actually proves sslv3 is on when it shouldn’t be!
When using SSLv3 to connect, settings of the default server{}
block will be used. This is because there is no SNI in SSLv3, and
hence SSL connection is established in the context of the default
server{} block. The appropriate server{} block is then selected
based on Host header in an http request, much like it used to work
with non-SNI virtual hosting and normal HTTP.
That is, by using the “ssl_protocols” directive you can only limit
use of SSLv3 for all servers on a particular listen socket, as due
to lack of SNI it doesn’t make sense in non-default server{}
blocks.
If you want to limit use of SSLv3 for a particular server only,
you have two basic options:
-
use a separate listen socket for this server (that is, use a
separate IP address);
-
test $ssl_protocol variable during a http request processing and
return an error; something like
if ($ssl_protocol = “SSLv3”) {
return 403;
}
will do the trick.
–
Maxim D.
http://nginx.org/
Hello!
On Thu, Oct 16, 2014 at 02:41:33PM +0100, Miguel C. wrote:
Hum… makes sense when sni is involved yes, but I get the same issue if
using the same certificate (wildcard) for 2 subdomains our my dev
environment.
say “blog.domain.com” and “forums.domain.com” and I tested with
cert/key_path define in the server’s blocks and in conf.d/ssl.conf (which
is read before site-enabled/*) both give the same result
This are curl result with any ssl path/cipher striped form server blocks,
and in one ssl_protocol as sslv3 (forums) the other does not
[…]
NOTE: the blog config is read first… if I rename the forums config to
00-forums.conf SSLv3 works, but works for both and it should not work for
blog… so It seems that its not only about sni?
Again: as long as SSLv3 is not enabled in the default server
block, SSLv3 will not work. If it’s enabled, it will work for all
virtual servers using the listen socket in question. By chaning
names you effectively change default server for the listen socket in
question (but that’s bad and not guaranteed to work, use
“listen … default_server” instead). That’s expected behaviour.
Quoting my previous response here, you may want to re-read it to
make sure you’ve understood it correctly:
blocks.
if ($ssl_protocol = “SSLv3”) {
return 403;
}
will do the trick.
Addditionally, here are link to article about request processing
in nginx, it explains things about “default_server” and so on:
http://nginx.org/en/docs/http/request_processing.html
Hope this helps.
–
Maxim D.
http://nginx.org/
On Thu, Oct 16, 2014 at 2:58 PM, Maxim D. removed_email_address@domain.invalid
wrote:
is read before site-enabled/*) both give the same result
Again: as long as SSLv3 is not enabled in the default server
block, SSLv3 will not work. If it’s enabled, it will work for all
virtual servers using the listen socket in question. By chaning
names you effectively change default server for the listen socket in
question (but that’s bad and not guaranteed to work, use
“listen … default_server” instead). That’s expected behaviour.
Quoting my previous response here, you may want to re-read it to
make sure you’ve understood it correctly:
Duh, yes I get it now, its not possible to do this with sslv3 enable by
default (also I do have default_server on ssl.conf)
server {
listen 443 default_server ssl spdy;
server_name _;
ssl_certificate wildcard.crt;
ssl_certificate_key wildcard.key;
}
This just makes it use the cert for all and uses this as default (which
as
you say is preferred to just setting it on the server block and expect
nginx uses the first as default.
I was using ssl_protocols TLSv1 TLSv1.1 TLSv1.2; or ssl_protocols SSLv3
TLSv1 TLSv1.1 TLSv1.2; in the servers only and the moved it to ssl.conf.
And what you say is that *the expect behaviour" is that if SSLv3 is on
then
its on for all, and if not its off for all, it will use the default
config
(or first it grabs although its not the recommend case).
So as I said somewhere before this is indeed on for all or for none, but
its not a bug, its how it works, there is no way around it except using
a
different socket (IP) for each server!
I was wrongly expecting it would work different with a wildcard cert.
Thanks for the clarification
Hello
When using SSLv3 to connect, settings of the default server{}
block will be used. This is because there is no SNI in SSLv3, and
hence SSL connection is established in the context of the default
server{} block
Even with TLSv1.1 and TLSv1.2, default server “ssl_protocols” is only in
effect.
server {
listen 443 ssl;
server_name a.example.com;
ssl_certificate cert.pem;
ssl_certificate_key cert.key;
ssl_protocols TLSv1.1 TLSv1.2;
}
server {
listen 443 ssl default_server;
server_name “”;
ssl_certificate cert.pem;
ssl_certificate_key cert.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
}
openssl s_client -connect a.example.com:443 -servername a.example.com
-tls1
(success)
TLSv1 is disabled in a.example.com but TLSv1 request is successful.
server {
listen 443 ssl;
server_name a.example.com;
ssl_certificate cert.pem;
ssl_certificate_key cert.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
}
server {
listen 443 ssl default_server;
server_name “”;
ssl_certificate cert.pem;
ssl_certificate_key cert.key;
ssl_protocols TLSv1.2;
}
openssl s_client -connect a.example.com:443 -servername a.example.com
-tls1_1 (failed)
TLSv1, TLSv1.1, TLSv1.2 is enabled for a.example.com but TLSv1 and
TLSv1.1
requests get failed.
So, even with SNI clients default_server “ssl_protocols” is only
selected.
Posted at Nginx Forum:
Hello!
On Fri, Nov 07, 2014 at 04:23:58AM -0500, saravsars wrote:
Hello
When using SSLv3 to connect, settings of the default server{}
block will be used. This is because there is no SNI in SSLv3, and
hence SSL connection is established in the context of the default
server{} block
Even with TLSv1.1 and TLSv1.2, default server “ssl_protocols” is only in
effect.
In theory, this depends on the OpenSSL library behaviour and may
work as long as SNI is used - nginx does it’s best to update all
SSL options on SNI callback.
With current OpenSSL code it doesn’t seem to work though, as
protocols allowed are checked before SNI callback happens and not
rechecked afterwards. So yes, you are right - “ssl_protocols”
won’t do anything good in non-default server{} blocks, even if SNI
is used.
–
Maxim D.
http://nginx.org/