Nginx上的SSL握手协商非常慢


17

我使用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;

    }

}

该机器是Linode上的VPS,具有1 G的RAM。谁能告诉我SSL握手为何花了很长时间?

Answers:


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;

这将取代此答案中的早期建议,该建议已被删除以避免混淆。


RC4是不安全的,因此不适合在TLS中使用。“虽然已知RC4算法具有多种密码学弱点(有关出色的调查,请参见[26]),但以前尚未探讨如何在TLS的背景下利用这些弱点。在这里,我们展示了新的和最近的当使用RC4作为加密算法时,RC4密钥流中发现的偏差确实会在TLS中造成严重的漏洞。” 请参阅关于TLS和WPA中RC4的安全性

2
@noloader在我发帖数年后宣布Rc4攻击;直到最近,由于对TLS v1.0和更早版本的BEAST攻击,大多数密码学家都建议在AES上使用RC4。既然大多数浏览器都可以抵御BEAST客户端,并且对RC4进行了进一步的攻击,则建议已更改。有关TLS v1.2的一些不错的nginx设置,请参阅此帖子:blog.cloudflare.com/staying-on-top-of-tls-attacks
rmalayter 2014年

天啊!对于那个很抱歉。我没想到要检查日期。抱歉。

5

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

您的钥匙大小是多少?时间越长越慢。

尝试strace查看流程以了解它们在做什么。


+1似乎是一种很好的可能性,因为VPS上经常缺少urandom
Kyle Brandt 2010年

1

检查您是否不在某个地方等待DNS解析。


0

更改

ssl_protocols  SSLv2 SSLv3 TLSv1;

ssl_protocols  SSLv3 TLSv1 SSLv2;

按照列出的顺序尝试协议。


真的没有帮助。参见webpagetest.org/result/101020_8KVR/1/details-协商仍占整个时间的50%以上。
Paras Chopra

2
不应使用SSLv2,因为它不安全。在发表本文时,所有主流浏览器均应支持TLSv1,因此也不再需要SSLv3。(理想情况下,它应为TLSv1 TLSv1.1 TLSv1.2,直到大多数浏览器采用1.1为止)。
KBeezie
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.