O handshake SSL falhou com o nginx

Question

Eu tenho um servidor web por trás do nginx e tudo funciona bem, exceto por uma coisa. Eu estou tentando confirmar uma Assinatura Amazon SNS que precisa postar alguns parâmetros (com um url de confirmação) para o meu site antes de se tornar ativo. Todas as minhas tentativas falharam e eu pensei que era algo com a AWS demorando mais do que o esperado para postar ... até que eu abri os logs do nginx para ver se alguma requisição estava sendo enviada quando eu vi este erro crítico:

[crit] 6#6: *13 SSL_do_handshake() failed (SSL: error:14076102:SSL routines:SSL23_GET_CLIENT_HELLO:unsupported protocol) while SSL handshaking, client: 54.239.98.103, server: 0.0.0.0:443

Com ele sendo crítico, ele não permitirá que o pedido vá para o servidor da Web e confirme meu SNS.

Alguma idéia do que poderia ser a causa disso? Além disso, aqui está meu conf nginx:

worker_processes auto;
error_log /dev/stderr info;

user nobody nogroup;
pid /tmp/nginx.pid;
error_log /tmp/nginx.error.log;

events {
    worker_connections 1024;
    accept_mutex off;
}

http {
    include mime.types;
    default_type application/octet-stream;
    access_log /dev/stdout;
    sendfile on;
    keepalive_timeout 65;
    gzip on;
    gzip_disable "MSIE [1-6].(?!.*SV1)";
    gzip_vary on;

    upstream app_server {
        server unix:/tmp/gunicorn.sock fail_timeout=0;
    }

    server {
        #   redirect all http requests to https
        listen 80;
        listen [::]:80 ipv6only=on;
        return 301 https://$host$request_uri;
    }

    server {
        listen 443 ssl spdy;

        client_max_body_size 4G;
        server_name www.devcasts.io;
        keepalive_timeout 5;

        #   Use HTTP Strict Transport Security (HSTS)
        #   v. Django Doc: https://docs.djangoproject.com/en/1.7/topics/security/
        #   v. https://gist.github.com/plentz/6737338
        add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";

        #   ssl_session_cache caches session parameters that create the SSL/TLS
        #   connection. This cache, shared among all worker_connections, will
        #   drastically improve later requests since the connection setup
        #   information is already known. As a reference, a 1MB shared cache
        #   can hold approximately 4,000 sessions. As the timeout length is
        #   increased you will need a larger cache to store the sessions. The
        #   default timeout value for ssl_session_timeout is 5 minutes so to
        #   improve performance it can be increased to a several hours.

        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:50m;

        #   Session tickets store information about specific SSL/TLS sessions.
        #   When a client resumes interaction with an application the session
        #   ticket is used to resume the session without re negotiation. As an
        #   alternative to session tickets, session id's can be used. Session
        #   id's map to a specific session stored in the ssl_session_cache via
        #   a MD5 hash. Both mechanisms can be used to shortcut the SSL handshake.

        ssl_session_tickets on;

        ssl_dhparam /etc/nginx/ssl/dhparam.pem;

        location / {
            try_files $uri @proxy_to_app;
        }

        location @proxy_to_app {
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;
            proxy_redirect off;

            proxy_pass   http://app_server;
        }

        ssl_certificate /etc/nginx/ssl/devcasts.pem;
        ssl_certificate_key /etc/nginx/ssl/devcasts.key;

        ssl_protocols SSLv3 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:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
        ssl_prefer_server_ciphers on;

        ssl_stapling on;
        ssl_stapling_verify on;
        ssl_trusted_certificate /etc/nginx/ssl/trustchain.crt;
        resolver 8.8.8.8 8.8.4.4;
    }
}

    

Answer 1

SSL routines:SSL23_GET_CLIENT_HELLO:unsupported protocol

Isso significa que o cliente tentou se conectar usando o SSL2 enquanto você o proíbe explicitamente:

ssl_protocols SSLv3 TLSv1.1 TLSv1.2;

Isso é realmente uma coisa boa. SSL 2 e 3 são inseguros e estão sendo ativamente desencorajados. A menos que você precise dar suporte a clientes muito antigos, o uso de TSL1.0 ou posterior deve ser bom.