ウェブサイトのssl時間を削減する方法
HTTPS Webサイトを持っていますが、このWebサイトのSSL時間を短縮したいと考えています。 SSL証明書がAWS ELBにインストールされています。
オランダからこのサイトにアクセスすると、SSL時間が長くなりますが、他の国から同じサイトにアクセスすると、SSL時間が短くなります。何故ですか？
このページに表示されている時間を最小限に抑えるようにしています
http://tools.pingdom.com/fpt/#!/ed9oYJ/https://www.google.com/index.html
以下を含む多くのことがSSL時間に影響します。
インフラストラクチャ（これはSSLには影響しませんが、[〜＃〜] all [〜＃〜]ネットワークトラフィック）：
- SSL/TLSハンドシェイクが数回のラウンドトリップを行うため、標準的なネットワークの問題（サーバーからクライアントまでの距離、ネットワークの速度など）。ホスティングプロバイダーの変更やCDNの使用を除いて、これらをほとんど制御できません。 AWSは、私の経験では速く、一般的なアクセス時間ではなくSSLを改善するように求めているだけなので、今はこれをスキップしてください。
- サーバーの応答時間。サーバーの電源は、CPU、Ram、またはディスクで不足していますか？このホストを共有していますか？再び一般的な問題なので、これをスキップするかもしれませんが、SSL/TLSはある程度の処理能力を必要としますが、最近のサーバーでは、ほとんど目立ちません。
- サーバーOS。新しい方が良いです。たとえば、Red Hat Linux 4を実行している場合、ネットワークスタックが改善され、OpenSSLなどの主要なソフトウェアの新しいバージョンが搭載されているため、最新のRed Hat Linux 7よりもかなり低速になると予想されます。
SSLの設定（ https://www.ssllabs.com/ssltest を介してサイトを実行すると、正常な状態が得られます）：
- 使用される暗号。古くて遅い暗号と速くて新しい暗号があります。ここですぐに複雑になる可能性がありますが、一般的には、ほとんどのクライアント（およびECDHE ... GCMのものを推奨）のECDHE暗号を探し、サーバーの順序を使用してクライアントではなく使用する暗号を選択できるように指定する必要があります。 。
- 使用される証明書。 RSA 2048証明書が必要です。それ以上のものはやり過ぎで、遅いです。一部のサイト（および一部のスキャンツール）はRSA 4096証明書を選択しますが、これらは速度に顕著な影響を及ぼし、実際にはセキュリティは向上しません（現時点では変更される可能性があります）。新しいECDSA証明書（通常はssllabsレポートでは256 EC証明書として表示されます）がありますが、これらのより高速なECDSA証明書はすべてのCAから提供されているわけではなく、すべてのクライアントによって普遍的にサポートされているわけではないため、古いハードウェアおよびソフトウェアの訪問者は接続できない場合がありますそれら。 Apache（ 、およびごく最近のv 1.11.0 からのNginx）は、2つの証明書をサポートしますが、2つの証明書があり、設定がいくらか複雑になります。
- 証明書チェーン。短い証明書チェーンが必要です（理想的な3つの証明書：サーバー、仲介者、およびCAルート証明書）。サーバーは、最後の証明書（既にブラウザーの証明書ストアにある）以外のすべてを返す必要があります。チェーンのいずれかが欠落している場合、一部のブラウザーは不快なものを探しますが、これには時間がかかります。
- 信頼できる証明書プロバイダー。証明書チェーンが短く、OCSPレスポンダーが優れているだけでなく、それらの仲介者も他のサイトで使用される可能性が高いため、通常はユーザーのブラウザーにキャッシュされます。
- OCSP Staplingは、OCSPまたはCRLを使用して、証明書が有効であることを確認するためのネットワーク旅行を節約します。 Chrome彼らは失効をチェックしないため、これをオンにしても違いはありません（ただし、EV証明書はチェックされます）。IEサーバーでサポートされている場合は有効にする必要がありますが、 実装の問題 に注意してください。特に、OCSP Staplingが有効になっていると、再起動後のnginxの最初のリクエストは常に失敗します。
- 古いクライアントにはTLSv1.2を使用し、場合によってはTLSv1.0を使用する必要がありますが、SSLv2とSSLv3は使用しません。 TLSv1.1は一種の無意味です（サポートするほとんどすべての人が、より新しくより優れたTLSv1.2もサポートしています）。 TLSv1.3は現在取り組んでおり、いくつかの優れたパフォーマンスの改善がありますが、いくつかの既知の互換性の問題があるため、まだ完全に標準化されていません。うまくいけば、これらはすぐに使用できるように解決されるでしょう。 PCIコンプライアンス（サイトでクレジットカードを使用している場合）は、新しいサイトおよびすべてのサイトで2018年6月30日までにTLSv1.2以上を要求することに注意してください。
繰り返しアクセス-上記は初期接続に役立ちますが、ほとんどのサイトはいくつかのリソースをダウンロードする必要があり、設定が不適切な場合は毎回ハンドシェイク全体を実行する必要があります（これは、SSL接続のセットアップが繰り返されている場合は明らかです） webpagetest.orgなどの実行時の各リクエスト）：
- HTTPキープアライブをオンにして、各HTTP要求の後に接続がドロップされないようにする必要があります（これはHTTP/1.1実装のデフォルトです）。
- 私の意見では、SSLキャッシングとチケットはオンになっているはずです。 TLSv1.3 で修正する必要があるあいまいなセキュリティ上の理由については意見の相違がありますが、パフォーマンス上の理由から、オンにする必要があります。機密性の高い情報を持つサイトは、パフォーマンスよりも完全なセキュリティを選択する可能性がありますが、私の意見では、セキュリティの問題を悪用するのは非常に複雑であり、パフォーマンスの向上は顕著です。
- HTTP/2は、1つの接続のみ（したがって、1つのSSL/TLSセットアップのみ）を開き、他のパフォーマンスが向上しているため、検討する必要があります。
上記の場合（もしあれば）改善できるものがあるかどうかを確認するには、本当にあなたのサイトを知る必要があります。それを提供する気がない場合は、ssllabsテストを実行し、理解できないことについては、理解するために多くの詳細な知識が必要になる可能性があるので、助けを求めることをお勧めします。
それが役立つ場合は、これらの概念のいくつかをより詳細に説明する個人ブログを実行します。 https://www.tunetheweb.com/security/https/
ECDSA証明書を試すことができます： https://scotthelme.co.uk/ecdsa-certificates/
ただし、httpsのコストは最初のリクエストでのみ表示されます。セッションチケットは他のすべてのリクエストのコストを回避します。彼らは活性化されていますか？ （ssllabs.comで確認できます）
SPDYまたはhttp2を使用できる場合は、速度も向上する可能性があります。
ECDSAキー、SPDYおよびhttp2は、必要なラウンドトリップの数を減らすため、2つの場所の違いを減らす必要があります。
あなたはCDNを使用しているではないと言いますが、私はあなたがすべきであると信じていますなる。理由は次のとおりです。
TLS/SSLを介した接続には安全な接続のハンドシェイクが含まれ、クライアントとサーバー間の追加の通信が必要ですbeforeデータが流れ始めることができます。 このリンクには、SSLハンドシェイクの便利な図があります 、および このリンクでは、HTTPS接続の最初の数ミリ秒について説明しています 。
Jordan SisselがSSLハンドシェイクレイテンシの経験について書いた ：
HTTPとHTTPS間の同様のリクエストのレイテンシの違いの調査を開始しました。 ...それはすべて握手です。 ...ポイントは、SSLアクセラレータ（ハードウェアロードバランサーなど）がどれほど高速であっても、SSLエンドポイントがユーザーの近くにない場合、最初の接続が遅くなることです。
CDNを使用する場合、クライアントと最も近いEdgeの場所の間でハンドシェイクを行うことができ、レイテンシが劇的に改善されます。