nginx SSL 握手失败

nginx SSL 握手失败

我在 nginx 后面有一个 Web 服务器,除了一件事之外,其他一切都运行良好。我正在尝试确认一个 amazon SNS 订阅,它需要将一些参数(带有确认 URL)发布到我的网站才能生效。我所有的尝试都失败了,我以为是 AWS 花了比预期更长的时间发布……直到我打开 nginx 日志查看是否有任何请求被发送,这时我看到了这个严重错误:

[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

由于情况至关重要,它不会让请求进入网络服务器并确认我的 SNS。

你知道这可能是什么原因造成的吗?另外,这是我的 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;
    }
}

答案1

SSL routines:SSL23_GET_CLIENT_HELLO:unsupported protocol

这意味着客户端尝试使用 SSLv2 进行连接,而您明确禁止它:

ssl_protocols SSLv3 TLSv1.1 TLSv1.2;

这其实是一件好事。SSL v2 和 v3 不安全,因此不建议使用。除非您需要支持非常老的客户端,否则使用 TLSv1.0 或更高版本应该没问题。

相关内容