Đàm phán bắt tay SSL trên Nginx cực kỳ chậm


17

Tôi đang sử dụng Nginx làm proxy cho 4 trường hợp apache. Vấn đề của tôi là đàm phán SSL mất rất nhiều thời gian (600 ms). Xem đây là một ví dụ: http://www.webpagetest.org/result/101020_8JXS/1/details/

Đây là Nginx Conf của tôi:

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;

    }

}

Máy là VPS trên Linode với RAM 1 G. Bất cứ ai có thể xin vui lòng cho biết tại sao SSL Hand lắc mất nhiều thời gian?

Câu trả lời:


11

Bạn cần phải vô hiệu hóa mật mã "phù du diffie-hellman". Các trình duyệt không sử dụng chúng, nhưng openSSL sẽ được sử dụng với các công cụ như cURL hoặc apachebench. Vì vậy, tôi cá cược rằng webpagetest.org đang sử dụng chúng.

Xem chủ đề này để biết thêm chi tiết.

Cá nhân tôi sử dụng các cài đặt này trong nginx để buộc các mật mã SSL nhanh nhất nhưng vẫn an toàn dựa trên tùy chọn của máy chủ chứ không phải các trình duyệt:

Cập nhật 2014-01-13: Lời khuyên này đã thay đổi khi có các cuộc tấn công gần đây vào RC4, các bản cập nhật trình duyệt bảo vệ chống lại BEAST và tính khả dụng rộng rãi hơn của TLS v1.2 trong máy khách và máy chủ.

Đã cập nhật 2015-10-16: cài đặt TLS nginx hiện tại 2015-10-16 theo khuyến nghị của CloudFlare . Vui lòng kiểm tra liên kết tiến hành để cập nhật, vì TLSv1 có thể sẽ bị xóa khỏi cấu hình được đề xuất tại một số điểm. Các cài đặt hiện tại vô hiệu hóa SSLv3 và RC4 theo thông lệ tốt nhất hiện tại và PCI-DSS mới nhất kể từ ngày này.

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;

Điều này thay thế cho lời khuyên trước đó trong câu trả lời này, đã được gỡ bỏ để tránh bị đốt cháy.


RC4 không an toàn và không phù hợp sử dụng fr trong TLS. "Mặc dù thuật toán RC4 được biết là có nhiều điểm yếu về mật mã (xem [26] để có một khảo sát xuất sắc), nhưng trước đây chúng ta chưa khám phá làm thế nào những điểm yếu này có thể được khai thác trong bối cảnh của TLS. đã phát hiện ra những sai lệch trong dòng khóa RC4 tạo ra các lỗ hổng nghiêm trọng trong TLS khi sử dụng RC4 làm thuật toán mã hóa của nó. " Xem phần Bảo mật của RC4 trong TLS và WPA .

2
@noloader rằng cuộc tấn công Rc4 đã được công bố nhiều năm sau bài đăng của tôi; cho đến gần đây, hầu hết các nhà mật mã học đã khuyến nghị RC4 hơn AES vì cuộc tấn công BEAST chống lại TLS v1.0 trở về trước. Giờ đây, hầu hết các trình duyệt bảo vệ chống lại phía khách hàng của BEAST và đã có thêm các cuộc tấn công chống lại RC4, lời khuyên đã thay đổi. Xem bài đăng này để biết một số cài đặt nginx tốt cho TLS v1.2: blog.cloudflare.com/staying-on-top-of-tls-attacks
rmalayter

Ôi trời! Xin lỗi vì điều đó. Tôi đã không nghĩ để kiểm tra ngày. Lấy làm tiếc.

5

Bạn có thể không có một nguồn entropy tốt. Có /dev/urandomtồn tại? Nếu không Nginx sẽ chặn đọc /dev/random.

Kích thước của chìa khóa của bạn là gì? Lâu hơn là chậm hơn.

Hãy thử straceing các quy trình để xem những gì họ đang làm.


+1 Có vẻ như là một khả năng tốt vì urandom thường bị thiếu trên VPS
Kyle Brandt

1

kiểm tra xem bạn không chờ đợi độ phân giải DNS ở đâu đó.


0

Thay đổi

ssl_protocols  SSLv2 SSLv3 TLSv1;

đến

ssl_protocols  SSLv3 TLSv1 SSLv2;

Thử các giao thức theo thứ tự mà chúng được liệt kê.


Không thực sự giúp đỡ. Xem webpagetest.org/result/101020_8KVR/1/details - đàm phán vẫn chiếm> 50% toàn bộ thời gian.
Paras Chopra

2
SSLv2 KHÔNG nên được sử dụng, nó không an toàn. Tại thời điểm nhận xét này, tất cả các trình duyệt chính nên hỗ trợ TLSv1 vì vậy SSLv3 không còn cần thiết nữa. (lý tưởng nhất là TLSv1 TLSv1.1 TLSv1.2 cho đến khi hầu hết các trình duyệt chấp nhận 1.1).
KBeezie
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.