Hello
I seem to have a bit of a problem. In my vhost’s server {}; block, I
have:
ssl_ciphers
EECDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AESGCM:EDH+aRSA+AES:DES-CBC3-SHA:!EXP:!CAMELLIA:!DSS:!MEDIUM:!LOW:!aNULL:!eNULL:!RC4;
ssl_prefer_server_ciphers on;
but for some reason this doesn’t seem to be respected because
ssllabs.com’s
checker says:
“RC4 cipher is used with TLS 1.1 or newer protocols, even though
stronger
ciphers are available.”
Testing with openssl s_client shows:
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-RC4-SHA
My ssl_ciphers line should be disallowing all RC4… so I am not sure
if
this is a bug or if I have these options in the wrong place (I tried
them
in the http{} block for grins with no effect) or if there’s something
missing from my build. Can someone provide guidance?
TIA.
-jkl
root@dreamer:~# which nginx
/usr/sbin/nginx
root@dreamer:~# /usr/sbin/nginx -V
nginx version: nginx/1.7.6
built by gcc 4.7.2 (Debian 4.7.2-5)
TLS SNI support enabled
configure arguments: --prefix=/opt/nginx --with-http_ssl_module
–with-http_gzip_static_module --with-http_stub_status_module
–with-cc-opt=-Wno-error
–add-module=/usr/local/rvm/gems/ruby-2.1.3/gems/passenger-4.0.53/ext/nginx
–sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf
–error-log-path=/var/log/nginx/error.log
–http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid
–lock-path=/var/run/nginx.lock
–http-client-body-temp-path=/var/cache/nginx/client_temp
–http-proxy-temp-path=/var/cache/nginx/proxy_temp
–http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
–http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
–http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx
–group=nginx
–with-http_ssl_module --with-http_realip_module
–with-http_addition_module --with-http_sub_module
–with-http_dav_module
–with-http_flv_module --with-http_mp4_module --with-http_gunzip_module
–with-http_gzip_static_module --with-http_random_index_module
–with-http_secure_link_module --with-http_stub_status_module
–with-mail
–with-mail_ssl_module --with-file-aio --with-http_spdy_module
–with-cc-opt=‘-s -O3 -fstack-protector --param=ssp-buffer-size=4
-Wformat
-Werror=format-security -Wno-error=maybe-uninitialized
-Wp,-D_FORTIFY_SOURCE=2’ --with-ld-opt=-Wl,-z,relro --with-ipv6
–add-module=/opt/build/naxsi-master/naxsi_src
root@dreamer:~# ldd /usr/sbin/nginx
linux-vdso.so.1 => (0x00007fffb808d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f6f3cf7a000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1
(0x00007f6f3cd43000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f6f3ca3b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
(0x00007f6f3c7b9000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
(0x00007f6f3c5b1000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3
(0x00007f6f3c373000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
(0x00007f6f3c113000)
libcrypto.so.1.0.0 =>
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x00007f6f3bd1b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
(0x00007f6f3bb16000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
(0x00007f6f3b8ff000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f6f3b6e9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
(0x00007f6f3b35d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6f3d1a0000)
root@dreamer:~# openssl version
OpenSSL 1.0.1e 11 Feb 2013
At least update your openssl to 1.0.1j and try again.
Posted at Nginx Forum:
Hello!
On Thu, Oct 16, 2014 at 03:40:44AM -0400, Jessica Litwin wrote:
this is a bug or if I have these options in the wrong place (I tried them
in the http{} block for grins with no effect) or if there’s something
missing from my build. Can someone provide guidance?
Configuring ssl_ciphers at http{} level should be fine - as long
as it’s not overwritten in server{} blocks.
Some thrivial things to check:
-
make sure ssl_ciphers isn’t overwritten in server{} blocks;
-
make sure you’ve properly reloaded you configuration. If you
used configuration reload (not nginx restart) - make sure to
check logs to see if reload went fine, as nginx will revert to a
previous configuration in case of errors. Additionally, “nginx -t”
may be helpful here.
-
make sure you are testing correct server.
–
Maxim D.
http://nginx.org/
hi,
- make sure you are testing correct server.
i’d suggest to configure an additional access/error-log
in that server {} - block, to be 100% sure.
regards,
mex
Posted at Nginx Forum:
I’m sure. I’m very, very sure the correct site is being tested.
Hi,
Everything is loading OK and nginx -t (or service nginx configtest) show
the config is ok and I am testing the correct server.
Another poster suggested upgrading openssl to 1.0.1j but I’d have to
build
from source to do that and I’m not sure what affect it would have
against
nginx…
I’m personally partial to just outright declaring my supported ciphers
rather than using the exclusion bits. My personal server is aggressively
strict, the setup for our production gear is much less so. Either way it
allows me to know exactly what’s available to clients.
For lunatics with DSA keys and LibreSSL:
ssl_ciphers
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256;
For more rational people with RSA keys and OpenSSL:
ssl_ciphers
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DES-CBC3-SHA;
__________________Scott LarsonSystems AdministratorWiredrive/LA310 823
8238 ext. 1106310 943 2078 faxwww.wiredrive.com
http://www.wiredrive.com/www.twitter.com/wiredrive
http://www.twitter.com/wiredriveWiredrive
http://www.wiredrive.com/facebook
what does cipherscan says?
you can run that from the server nginx runs on
Posted at Nginx Forum:
I can do this, but I guess my whole question was does this mean
exclusion
bits are broken?
I’m personally partial to just outright declaring my supported
ciphers
rather than using the exclusion bits. My personal server is aggressively
strict, the setup for our production gear is much less so. Either way it
allows me to know exactly what’s available to clients.
For lunatics with DSA keys and LibreSSL:
ssl_ciphers
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256;
For more rational people with RSA keys and OpenSSL:
ssl_ciphers
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DES-CBC3-SHA;
__________________Scott LarsonSystems AdministratorWiredrive/LA310 823
8238 ext. 1106310 943 2078 faxwww.wiredrive.com
http://www.wiredrive.com/www.twitter.com/wiredrive
http://www.twitter.com/wiredriveWiredrive
http://www.wiredrive.com/facebook
Something else must be going on here. Looking at your ssl_cipher
string, you’re opening with a rough declaration of specific ciphers
you’ll
support, none of which should pull in RC4. It’s specific enough in fact
that your subsequent excluded ciphers don’t even come into play. To test
this I switched in my old RSA cert, rebuilt 1.7.6 against OpenSSL
1.0.1j,
and hit it with nmap --script ssl-enum-ciphers www.ossuary.net and the
results with your exact string and removing the exclusions returned
identical supported options from the server on both runs, none of which
were RC4.
As for the location, in my tests this was defined within the
server{}
block. Without seeing your entire config, if you witness RC4 as truly
being
offered my guesses would be that it’s declared in a place which is being
ignored so nginx falls back to the default value, there is a second less
strict declaration somewhere (maybe in an include) overriding it, or
there
is a proxy in front which is doing the actual termination.
__________________Scott LarsonSystems AdministratorWiredrive/LA310 823
8238 ext. 1106310 943 2078 faxwww.wiredrive.com
http://www.wiredrive.com/www.twitter.com/wiredrive
http://www.twitter.com/wiredriveWiredrive
http://www.wiredrive.com/facebook
Scott Larson Wrote:
Something else must be going on here. Looking at your ssl_cipher
string, you’re opening with a rough declaration of specific ciphers
you’ll
support, none of which should pull in RC4. It’s specific enough in
fact
that your subsequent excluded ciphers don’t even come into play. To
test
this I switched in my old RSA cert, rebuilt 1.7.6 against OpenSSL
1.0.1j,
Which is why I said try 101j, between 101e and j there are big
differences
when it comes to invalid fallbacks.
Not even mentioning using 101e is asking to be hacked.
Posted at Nginx Forum:
using openssl101j, I get the same results with the following in both my
vhost config and nginx.conf
ssl_protocols TLSv1.2 TLSv1.1;
ssl_ciphers
EECDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AESGCM:EDH+aRSA+AES:DES-CB
C3-SHA:!EXP:!CAMELLIA:!DSS:!MEDIUM:!LOW:!aNULL:!eNULL:!RC4;
ssl_prefer_server_ciphers on;
RC4 cipher is used with TLS 1.1 or newer protocols, even though stronger
ciphers are available.
What the hell am I doing wrong?
no, not that domain. i’ll contact you off-list 
Just to be thorough, are you sure nginx is actually using the config
file that you think it is? If we’re talking about your personal domain I
see TLS 1.0 and SSL 3.0 available which in this snippet you have not
enabled. This behavior isn’t something I’m able to replicate with the
1.7.6/1.0.1i combo.
Scott Larson
Systems Administrator
Wiredrive/LA
310 823 8238 ext. 1106
310 943 2078 fax
www.wiredrive.com http://www.wiredrive.com/
www.twitter.com/wiredrive http://www.twitter.com/wiredrive
Wiredrive http://www.wiredrive.com/facebook
This was fun…
I found a subdomain’s vhost was allowing RC4, and fixing that the RC4
alert
go away for scanning the main site. I think this might be an issue with
the
way the Qualys scanner works. Thank you all for helping & kudos to Scott
Larson for putting up with me 
-jkl
maybe related (maxims answer)
Posted at Nginx Forum: