SSL handshake failed with nginx

Question

I have a web server behind nginx and everything works well except for one thing. I'm trying to confirm an amazon SNS Subscription which needs to post some parameters (with a confirmation url) to my website before becoming active. All my attempts failed and I thought it's something with AWS taking longer than expected to post...until I opened up the nginx logs to see if any requests are being sent at all when I saw this critical error:

[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

With it being critical it won't let the request go to the web server and confirm my SNS.

Any ideas what could be the cause of this? Also, here's my nginx conf:

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

This means that the client tried to connect using SSLv2 while you explicitly forbid it:

ssl_protocols SSLv3 TLSv1.1 TLSv1.2;

This is actually a good thing. SSL v2 and v3 are insecure and are being actively discouraged. Unless you need to support very old clients, using TLSv1.0 or later should be fine.