Negoziazione di handshake SSL su Nginx terribilmente lenta


17

Sto usando Nginx come proxy per 4 istanze di Apache. Il mio problema è che la negoziazione SSL richiede molto tempo (600 ms). Vedi questo come esempio: http://www.webpagetest.org/result/101020_8JXS/1/details/

Ecco il mio 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;

    }

}

La macchina è un VPS su Linode con 1 G di RAM. Qualcuno può dire perché SSL Hand Shake sta invecchiando?

Risposte:


11

Devi disabilitare le cifre "effimero diffie-hellman". I browser non li usano comunque, ma openSSL verrà utilizzato con strumenti come cURL o apachebench. Quindi scommetto che webpagetest.org li sta usando.

Vedi questa discussione per maggiori dettagli.

Personalmente utilizzo queste impostazioni in nginx per forzare le crittografie SSL più veloci ma ancora sicure in base alle preferenze del server e non ai browser:

Aggiornamento 2014-01-13: questo consiglio è cambiato a causa dei recenti attacchi a RC4, degli aggiornamenti del browser che proteggono da BEAST e della disponibilità più diffusa di TLS v1.2 in client e server.

16-10-2015 aggiornato: impostazioni TLS nginx correnti 16-10-2015 come raccomandato da CloudFlare . Verificare il collegamento precedente per gli aggiornamenti, poiché TLSv1 sarà probabilmente rimosso dalla configurazione consigliata ad un certo punto. Le impostazioni correnti disabilitano SSLv3 e RC4 in conformità con le migliori pratiche attuali e l'ultimo PCI-DSS a partire da questa data.

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;

Questo sostituisce il precedente consiglio in questa risposta, che è stato rimosso per evitare confusione.


RC4 è insicuro e non adatto all'uso in TLS. "Sebbene sia noto che l'algoritmo RC4 presenta una varietà di punti deboli crittografici (si veda [26] per un eccellente sondaggio), non è stato precedentemente esplorato come questi punti deboli possano essere sfruttati nel contesto di TLS. Qui mostriamo che nuovi e recenti i pregiudizi rilevati nel flusso di chiavi RC4 creano serie vulnerabilità in TLS quando si utilizza RC4 come algoritmo di crittografia ". Vedi sulla sicurezza di RC4 in TLS e WPA .

2
@noloader che l'attacco Rc4 è stato annunciato anni dopo il mio post; fino a poco tempo fa la maggior parte dei crittografi raccomandava RC4 su AES a causa dell'attacco BEAST contro TLS v1.0 e precedenti. Ora che la maggior parte dei browser protegge da BEAST sul lato client e ci sono stati ulteriori attacchi contro RC4, il consiglio è cambiato. Vedi questo post per alcune buone impostazioni di nginx per TLS v1.2: blog.cloudflare.com/staying-on-top-of-tls-attacks
rmalayter

Oh mio! Mi dispiace per quello. Non pensavo di controllare le date. Scusa.

5

Potresti non avere una buona fonte di entropia. Esiste /dev/urandom? Altrimenti Nginx bloccherà la lettura /dev/random.

Qual è la dimensione della tua chiave? Più è più lento.

Prova stracei processi per vedere cosa stanno facendo.


+1 Sembra una buona possibilità in quanto urandom spesso manca sui VPS
Kyle Brandt,

1

controlla che non stai aspettando la risoluzione DNS da qualche parte.


0

Modificare

ssl_protocols  SSLv2 SSLv3 TLSv1;

per

ssl_protocols  SSLv3 TLSv1 SSLv2;

Cerca i protocolli nell'ordine in cui sono elencati.


Non ha davvero aiutato. Vedi webpagetest.org/result/101020_8KVR/1/dettagli - la negoziazione impiega ancora> 50% dell'intero tempo.
Paras Chopra,

2
SSLv2 NON deve essere utilizzato, non è sicuro. Al momento di questo commento tutti i principali browser dovrebbero supportare TLSv1, quindi SSLv3 non dovrebbe più essere necessario. (idealmente dovrebbe essere TLSv1 TLSv1.1 TLSv1.2 fino a quando la maggior parte dei browser adotta 1.1).
KBeezie,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.