Nginx에서 SSL 핸드 셰이크 협상이 너무 느림


17

4 개의 아파치 인스턴스에 프록시로 Nginx를 사용하고 있습니다. 내 문제는 SSL 협상에 많은 시간 (600ms)이 걸린다는 것입니다. 예를 들어 이것을 참조하십시오 : 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;

    }

}

이 시스템은 1G RAM을 가진 Linode의 VPS입니다. SSL 핸드 쉐이크가 왜 오래 걸리는지 말해 줄 수 있습니까?

답변:


11

"일시적인 diffie-hellman"암호를 비활성화해야합니다. 브라우저는 어쨌든 사용하지 않지만 cURL 또는 apachebench와 같은 도구와 함께 사용하면 openSSL이 사용됩니다. 그래서 나는 webpagetest.org가 그것들을 사용하고 있다고 확신합니다.

자세한 내용은 이 스레드 를 참조하십시오.

개인적으로 nginx에서 이러한 설정을 사용하여 브라우저가 아닌 서버의 환경 설정에 따라 가장 빠르지 만 여전히 안전한 SSL 암호를 사용합니다.

2014-01-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

어머! 미안합니다. 나는 날짜를 확인하지 않았다. 죄송합니다.

5

엔트로피 소스가 좋지 않을 수 있습니다. 않는 /dev/urandom존재 하는가? 그렇지 않으면 Nginx가 읽기를 차단합니다 /dev/random.

키의 크기는 얼마입니까? 길어질수록 느려집니다.

시도 strace그들이 무엇을하고 있는지 확인하기 위해 프로세스를 보내고.


+1 VPS에서 urandom이 종종 누락 될 가능성이 높습니다.
Kyle Brandt

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도 더 이상 필요하지 않습니다. (대부분의 브라우저에서 1.1을 채택 할 때까지 TLSv1 TLSv1.1 TLSv1.2 여야합니다).
KBeezie
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.