3

An SSLLabs security test of our site says it's vulnerable to POODLE. This tutorial told me I should switch off SSL3. But when I checked our nginx .conf file for the website SSL3 was already off. What is happening?

# Installed by APT
# serves static files, and passes 404 image requests onto PHP
upstream backend_rental {
    server unix:/srv/rental/tmp/php.sock;
}

# force ekaya.co calls to ekaya.com
server {
    server_name ekaya.co;
    listen 80;
    listen 443;

    ssl on;
    ssl_certificate /etc/ssl/local/ekaya.co.crt;
    ssl_certificate_key /etc/ssl/local/ekaya.co.key;
    ssl_session_timeout 5m;
    ssl_session_cache shared:SSL:50m;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
    ssl_prefer_server_ciphers on;

    add_header Strict-Transport-Security max-age=15768000;

    rewrite ^ https://ekaya.com$request_uri? permanent;
}

server {
    server_name ekaya.com ekaya.rental qa.ekaya.volk.co.za;
        listen 80;
    listen 443;

    ssl on;
#   ssl_certificate /etc/ssl/local/ekaya.com.crt;
#   ssl_certificate_key /etc/ssl/local/ekaya.com.key;
        ssl_certificate /etc/letsencrypt/live/ekaya.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/ekaya.com/privkey.pem;
    ssl_session_timeout 5m;
    ssl_session_cache shared:SSL:50m;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
    ssl_prefer_server_ciphers on;

    add_header Strict-Transport-Security max-age=15768000;
    add_header X-Clacks-Overhead "GNU Terry Pratchett";

    root /srv/rental/public;
    index index.html index.php;

    access_log /var/log/nginx/ekaya.access.log combined;
    error_log /var/log/nginx/ekaya.error.log;

    # Nginx status
    location /nginx_stub_status {
        # copied from http://blog.kovyrin.net/2006/04/29/monitoring-nginx-with-rrdtool/
        stub_status on;
        access_log off;
        allow 127.0.0.1;
        allow 196.201.6.140;
        deny all;
    }

    # PHP-FPM status
    location /php_status {
        access_log off;
        allow 127.0.0.1;
        allow 196.201.6.140;
        deny all;
        include fastcgi_params;
        fastcgi_pass backend_rental;
    }

    # set expiration of assets to MAX for caching
    location ~* \.(ico|css|js|gif|jpe?g|png)(\?[0-9]+)?$ {
        expires max;
    }

    location / {
        # Check if a file exists, or route it to index.php.
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~* \.php$ {
        fastcgi_pass backend_rental;
        fastcgi_index index.php;
        fastcgi_split_path_info ^(.+\.php)(.*)$;
        fastcgi_read_timeout 300;
        fastcgi_send_timeout 300;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}
  • Since the site is obviously open to SSL 3.0 (which can be verified with openssl s_client too) you either do not show the configuration used or there are settings in parts of the nginx configuration you don't show (this is obviously only a part of the configuration for nginx) – Steffen Ullrich Sep 26 '16 at 10:32
  • 1
    Maybe you have one of the TLSv1 implementations that are also vulnerable to POODLE. – David Schwartz Sep 26 '16 at 10:47
  • @DavidSchwartz: openssl s_client -ssl3... says clearly that the site has SSL 3.0 enabled. The linked report from SSLLabs says this too. Which means that the ssl_protocols line shown in the config must be superset by some config which is not shown (or maybe a reverse proxy in the path). – Steffen Ullrich Sep 26 '16 at 10:55
  • Thank you all for your detailed comments and answers. I don't understand most of them, but I have posted my full config above as you suggested. I will try Google what you are talking about if this config doesn't help any more. – Richard Sep 26 '16 at 12:56
1

Some seemingly trivial checks and questions:

  • Did you stop and restart your webserver to ensure that the actual configuration is really active?
  • Are you sure that you look at the configuration of the tested webserver (beware of virtual hosts etc.)?
  • Are you sure that you are looking at the right configuration file?
  • Thanks, I think so. 1) When I changed this config and restarted the site broke, suggesting I'm on the correct config. 2) We have no virtual hosts afaik. 3) I haven't changed the conf file in at least 6 months, when I joined the firm, and these TLS settings have been there the whole time. – Richard Sep 26 '16 at 9:59
  • 2
    Are you sure there is no reverse-proxy between your webserver and browser? – Josef Sep 26 '16 at 10:38
  • How do I determine this? – Richard Sep 26 '16 at 13:02
1

Can't comment so pardon me for making an answer out of what should really be a comment.

As mentioned by Steffen Ulrich, this is not the full configuration and it might not even be the one in effect (see the disabled caching when attempting to connect, enabled in the given configuration).

Also, from what I gather, your SSLv3 server is not the same as the one you are attempting to fix, mainly because they do not serve the same certificate. The TLS server correctly provides the Let's Encrypt certificate while the SSLv3 one provides an expired StartSSL certificate. You can have a look at what the SSLv3 server provides with curl -vvv --sslv3 --insecure https://ekaya.com.

Edit: The TLS vulnerability to POODLE does not originate in the ciphers but in the implementation of the server so you're safe there.

Check using OpenSSL's s_client

Expired cert via SSLv3:

$ echo '' | openssl s_client -connect ekaya.com:443 -servername ekaya.com -ssl3 2>&1 | grep -Ei 'protocol|cipher|subject|issuer|code'
subject=/description=8v0Dwh0DQ9LnEM7c/C=ZA/CN=agent.ekaya.co/emailAddress=webmaster@ekaya.co
issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
    Protocol  : SSLv3
    Cipher    : ECDHE-RSA-AES256-SHA
    Verify return code: 10 (certificate has expired)

Good cert via TLS v1.2:

$ echo '' | openssl s_client -connect ekaya.com:443 -servername ekaya.com -tls1_2 2>&1 | grep -Ei 'protocol|cipher|subject|issuer|code'
subject=/CN=ekaya.com
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Verify return code: 0 (ok)
  • The difference appears to be that s_client -ssl3 doesn't send ClientHello extensions and thus (silently) ignores -servername. s_client -tls1_2 OMITTING -servername also gets the StartCom cert, which is not only expired but also for agent.ekaya.co and ekaya.co NOT ekaya.com -- and it negotiates ECDHE-RSA with AES256GCM not AES128GCM which it gets with SNI ekaya.com as the posted config (with server preference) should do. Clearly there is indeed some additional config somewhere. – dave_thompson_085 Sep 26 '16 at 12:23
  • Thank you. What do you suggest I do? – Richard Sep 26 '16 at 13:03
  • 1
    At this point, I'd suggest determining if there is a reverse proxy, which I'm assuming there is. Look at the IPs of the servers, ekaya.com resolves to 196.201.6.140 so if you're looking at a machine with a different public IP address, that's not your entry point. Once you find the proper machine, netstat will help you determine what's listening on port 80 and 443. – Ginnungagap Sep 26 '16 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.