我在 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 或更高版本应该没问题。