web-dev-qa-db-ja.com

SSLハンドシェイクがnginxで失敗しました

Nginxの背後にWebサーバーがあり、1つを除いてすべてがうまく機能しています。 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

重要なので、リクエストがWebサーバーに送信されて私のSNSが確認されることはありません。

これの原因は何でしょうか？また、これが私の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;
    }
}
nginxsslssl-certificate
1
Romeo Mihalcea
SSL routines:SSL23_GET_CLIENT_HELLO:unsupported protocol

これは、クライアントがSSLv2を使用して接続しようとしたが、明示的に禁止したことを意味します。

ssl_protocols SSLv3 TLSv1.1 TLSv1.2;

これは実際には良いことです。 SSL v2とv3は安全ではなく、積極的に推奨されていません。非常に古いクライアントをサポートする必要がない限り、TLSv1.0以降を使用することで問題ありません。

1
Braiam