Nginx 上的 SSL 握手协商非常慢

Par*_*pra 18 linux ssl nginx

我使用 Nginx 作为 4 个 apache 实例的代理。我的问题是 SSL 协商需要很长时间(600 毫秒)。以这个为例:http : //www.webpagetest.org/result/101020_8JXS/1/details/

这是我的 Nginx Conf:

user www-data;
worker_processes  4;


events {
    worker_connections 2048;
    use epoll;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    access_log  /var/log/nginx/access.log;
    sendfile        on;
    keepalive_timeout  0;
    tcp_nodelay        on;
    gzip  on;
    gzip_proxied any;
    server_names_hash_bucket_size 128;


}

upstream abc {
     server 1.1.1.1 weight=1;
     server 1.1.1.2 weight=1;
     server 1.1.1.3 weight=1;


 }


server {
    listen   443;
    server_name  blah;

    keepalive_timeout 5;

    ssl  on;
    ssl_certificate  /blah.crt;
    ssl_certificate_key  /blah.key;
    ssl_session_cache  shared:SSL:10m;
    ssl_session_timeout  5m;
    ssl_protocols  SSLv2 SSLv3 TLSv1;
    ssl_ciphers RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
    ssl_prefer_server_ciphers   on;

    location / { proxy_pass http://abc;

                 proxy_set_header X-Real-IP  $remote_addr;
                 proxy_set_header Host $host;
                 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    }

}
Run Code Online (Sandbox Code Playgroud)

该机器是 Linode 上的 VPS,具有 1 G RAM。谁能告诉为什么 SSL 握手需要很长时间?

rma*_*ter 11

您需要禁用“临时 diffie-hellman”密码。浏览器无论如何都不会使用它们,但是当与 cURL 或 apachebench 等工具一起使用时,openSSL 会使用它们。所以我敢打赌,webpagetest.org 正在使用它们。

有关更多详细信息,请参阅此线程

我个人在 nginx 中使用这些设置来根据服务器的首选项强制使用最快但仍然安全的 SSL 密码,而不是浏览器:

2014 年 1 月 13 日更新:鉴于最近对 RC4 的攻击、防止 BEAST 的浏览器更新以及客户端和服务器中 TLS v1.2 的更广泛可用性,此建议已更改。

2015-10-16 更新:CloudFlare推荐的当前 nginx TLS 设置 2015-10-16 。请检查前面的链接以获取更新,因为 TLSv1 可能会在某个时候从推荐的配置中删除。当前设置根据当前最佳实践和截至目前的最新 PCI-DSS 禁用 SSLv3 和 RC4。

ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers                 EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_prefer_server_ciphers   on;
Run Code Online (Sandbox Code Playgroud)

这取代了本答案中较早的建议,该建议已被删除以避免混淆。

  • @noloader 在我发帖数年后宣布 Rc4 攻击;直到最近,由于针对 TLS v1.0 及更早版本的 BEAST 攻击,大多数密码学家都在推荐 RC4 而不是 AES。既然大多数浏览器都可以防御 BEAST 客户端,并且已经有针对 RC4 的进一步攻击,建议已经改变。有关 TLS v1.2 的一些不错的 nginx 设置,请参阅此帖子:http://blog.cloudflare.com/staying-on-top-of-tls-attacks (2认同)

Mar*_*ner 6

您可能没有良好的熵源。是否/dev/urandom存在?如果不是 Nginx 将阻止阅读/dev/random

你的钥匙尺寸是多少?时间越长越慢。

尝试运行strace这些进程,看看它们在做什么。