Negocjacje protokołu SSL u Nginx są strasznie wolne

17

Używam Nginx jako proxy do 4 instancji apache. Mój problem polega na tym, że negocjacja protokołu SSL zajmuje dużo czasu (600 ms). Zobacz to jako przykład: http://www.webpagetest.org/result/101020_8JXS/1/details/

Oto mój 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;

    }

}

Maszyna jest VPS na Linode z 1 G pamięci RAM. Czy ktoś może powiedzieć, dlaczego shake hand SSL trwa wieki?

Paras Chopra
źródło

Odpowiedzi:

11

Musisz wyłączyć szyfry „efemeryczny diffie-hellman”. Przeglądarki i tak ich nie używają, ale openSSL będzie używany, gdy będzie używany z narzędziami takimi jak cURL lub apachebench. Założę się, że webpagetest.org ich używa.

Zobacz ten wątek, aby uzyskać więcej informacji.

Osobiście korzystam z tych ustawień w nginx, aby wymusić najszybsze, ale wciąż bezpieczne szyfry SSL oparte na preferencjach serwera, a nie przeglądarki:

Aktualizacja 13.01.2014: Ta rada uległa zmianie, biorąc pod uwagę ostatnie ataki na RC4, aktualizacje przeglądarki chroniące przed BEAST oraz bardziej rozpowszechnioną dostępność TLS 1.2 na klientach i serwerach.

Zaktualizowano 16.10.2015: aktualne ustawienia TLS nginx 2015-10-16 zgodnie z zaleceniami CloudFlare . Sprawdź poprzedni link w celu uzyskania aktualizacji, ponieważ TLSv1 prawdopodobnie zostanie w pewnym momencie usunięty z zalecanej konfiguracji. Obecne ustawienia wyłączają SSLv3 i RC4 zgodnie z aktualnymi najlepszymi praktykami i najnowszą kartą PCI-DSS od tej daty.

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;

Zastępuje to wcześniejsze porady w tej odpowiedzi, które zostały usunięte, aby uniknąć konfliktu.

rmalayter
źródło
RC4 jest niepewny i nie nadaje się do użycia w TLS. „Chociaż wiadomo, że algorytm RC4 ma różnorodne słabości kryptograficzne (patrz [26] dla doskonałej ankiety), nie zbadano wcześniej, w jaki sposób można wykorzystać te słabości w kontekście TLS. Tutaj pokazujemy, że nowe i niedawno odkryte uprzedzenia w strumieniu kluczy RC4 stwarzają poważne luki w TLS, gdy używa się RC4 jako algorytmu szyfrowania. ” Zobacz: Bezpieczeństwo RC4 w TLS i WPA .
2
@noloader, że atak Rc4 został ogłoszony wiele lat po moim poście; do niedawna większość kryptografów rekomendowała RC4 zamiast AES z powodu ataku BEAST przeciwko TLS 1.0 i wcześniejszym. Teraz, gdy większość przeglądarek chroni przed BEAST po stronie klienta i nastąpiły kolejne ataki na RC4, porada się zmieniła. Zobacz ten post, aby zapoznać się
rmalayter
O mój! Przepraszam za to. Nie pomyślałem o sprawdzeniu dat. Przepraszam.
5

Możesz nie mieć dobrego źródła entropii. Czy /dev/urandomistnieje Jeśli nie, Nginx zablokuje się podczas czytania /dev/random.

Jaki jest rozmiar twojego klucza? Dłuższy jest wolniejszy.

Spróbuj straceprocesów, aby zobaczyć, co robią.

Mark Wagner
źródło
+1 Wydaje się, że to dobra możliwość, ponieważ na VPS często brakuje urandomu
Kyle Brandt
1

sprawdź, czy gdzieś nie czekasz na rozwiązanie DNS.

pjz
źródło
0

Zmiana

ssl_protocols  SSLv2 SSLv3 TLSv1;

do

ssl_protocols  SSLv3 TLSv1 SSLv2;

Próbuje protokoły w kolejności, w jakiej są wymienione.

saneczki
źródło
Naprawdę nie pomogło. Zobacz webpagetest.org/result/101020_8KVR/1/details - negocjacje nadal zajmują> 50% całego czasu.
Paras Chopra,
2
Protokół SSLv2 NIE powinien być używany, ponieważ jest niepewny. W momencie tego komentarza wszystkie główne przeglądarki powinny obsługiwać protokół TLSv1, więc protokół SSLv3 nie powinien już być potrzebny. (najlepiej powinien to być TLSv1 TLSv1.1 TLSv1.2, dopóki większość przeglądarek nie przyjmie wersji 1.1).
KBeezie,