NginxでのSSLハンドシェイクネゴシエーションが非常に遅い


17

Nginxを4つのApacheインスタンスのプロキシとして使用しています。私の問題は、SSLネゴシエーションに多くの時間(600ミリ秒)がかかることです。例としてこれを参照してください: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;

    }

}

マシンは、1 GのRAMを搭載したLinode上のVPSです。誰もがSSLハンドシェイクが古くなっている理由を教えてもらえますか?

回答:


11

「一時的なdiffie-hellman」暗号を無効にする必要があります。とにかくブラウザはそれらを使用しませんが、openURLはcURLやapachebenchのようなツールで使用されると使用されます。だから、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
Rc4攻撃が投稿の数年後に発表された@noloader。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が欠落していることが多いため、可能性が高いようです
カイルブラント

1

どこかでDNS解決を待っていないことを確認してください。


0

変化する

ssl_protocols  SSLv2 SSLv3 TLSv1;

ssl_protocols  SSLv3 TLSv1 SSLv2;

リストされている順序でプロトコルを試行します。


本当に助けにならなかった。webpagetest.org/result/101020_8KVR/1/detailsを参照してください-交渉は全体の50%を超えています。
パラチョプラ

2
SSLv2は使用しないでください。安全ではありません。このコメントの時点で、すべての主要なブラウザーはTLSv1をサポートする必要があるため、SSLv3も必要なくなります。(理想的には、ほとんどのブラウザーが1.1を採用するまで、TLSv1 TLSv1.1 TLSv1.2でなければなりません)。
KBeezie
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.