Negosiasi handshake SSL di Nginx sangat lambat


17

Saya menggunakan Nginx sebagai proksi ke 4 instance apache. Masalah saya adalah bahwa negosiasi SSL membutuhkan banyak waktu (600 ms). Lihat ini sebagai contoh: http://www.webpagetest.org/result/101020_8JXS/1/details/

Ini Nginx Conf saya:

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;

    }

}

Mesin ini adalah VPS pada Linode dengan 1 G RAM. Adakah yang bisa mengatakan mengapa hand shake SSL memakan waktu lama?

Jawaban:


11

Anda perlu menonaktifkan sandi "ephemeral diffie-hellman". Peramban tidak menggunakannya, tetapi openSSL akan bila digunakan dengan alat seperti cURL atau apachebench. Jadi saya bertaruh webpagetest.org menggunakannya.

Lihat utas ini untuk lebih jelasnya.

Saya pribadi menggunakan pengaturan ini di nginx untuk memaksa cipher SSL tercepat-tetapi-masih-aman berdasarkan preferensi server, dan bukan browser:

Pembaruan 2014-01-13: Saran ini telah berubah karena serangan terbaru pada RC4, pembaruan peramban yang melindungi terhadap BEAST, dan ketersediaan TLS v1.2 yang lebih luas di klien dan server.

Diperbarui 2015-10-16: pengaturan TLS nginx saat ini 2015-10-16 seperti yang direkomendasikan oleh CloudFlare . Silakan periksa tautan sebelumnya untuk pembaruan, karena TLSv1 kemungkinan akan dihapus dari konfigurasi yang disarankan di beberapa titik. Pengaturan saat ini menonaktifkan SSLv3 dan RC4 sesuai dengan praktik terbaik saat ini dan PCI-DSS terbaru pada tanggal ini.

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;

Ini menggantikan saran sebelumnya dalam jawaban ini, yang telah dihapus untuk menghindari kebingungan.


RC4 tidak aman dan tidak cocok untuk digunakan dalam TLS. "Meskipun algoritma RC4 diketahui memiliki berbagai kelemahan kriptografi (lihat [26] untuk survei yang sangat baik), belum pernah dieksplorasi sebelumnya bagaimana kelemahan ini dapat dieksploitasi dalam konteks TLS. Di sini kami menunjukkan bahwa baru dan baru-baru ini bias ditemukan dalam keystream RC4 memang menciptakan kerentanan serius dalam TLS ketika menggunakan RC4 sebagai algoritma enkripsi. " Lihat Pada Keamanan RC4 di TLS dan WPA .

2
@noloader bahwa serangan Rc4 diumumkan bertahun-tahun setelah posting saya; sampai saat ini sebagian besar cryptographers merekomendasikan RC4 lebih dari AES karena serangan BEAST terhadap TLS v1.0 dan sebelumnya. Sekarang sebagian besar browser melindungi terhadap sisi klien BEAST, dan ada serangan lebih lanjut terhadap RC4, saran telah berubah. Lihat posting ini untuk beberapa pengaturan nginx yang baik untuk TLS v1.2: blog.cloudflare.com/staying-on-top-of-tls-attacks
rmalayter

Astaga! Maaf soal itu. Saya tidak berpikir untuk memeriksa tanggal. Maaf.

5

Anda mungkin tidak memiliki sumber entropi yang bagus. Apakah /dev/urandomada Jika tidak, Nginx akan memblokir pembacaan /dev/random.

Berapa ukuran kunci Anda? Lebih lama lebih lambat.

Cobalah straceproses untuk melihat apa yang mereka lakukan.


+1 Sepertinya kemungkinan bagus karena urandom sering hilang di VPS
Kyle Brandt

1

periksa apakah Anda tidak menunggu resolusi DNS di suatu tempat.


0

Perubahan

ssl_protocols  SSLv2 SSLv3 TLSv1;

untuk

ssl_protocols  SSLv3 TLSv1 SSLv2;

Mencoba protokol sesuai urutannya.


Tidak terlalu membantu. Lihat webpagetest.org/result/101020_8KVR/1/details - negosiasi masih membutuhkan> 50% dari keseluruhan waktu.
Paras Chopra

2
SSLv2 TIDAK boleh digunakan, tidak aman. Pada saat komentar ini, semua browser utama harus mendukung TLSv1 sehingga SSLv3 tidak lagi diperlukan. (idealnya TLSv1 TLSv1.1 TLSv1.2 sampai sebagian besar browser mengadopsi 1.1).
KBeezie
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.