NginxサーバーのSSLセキュリティ構成とCVE-2016-2183の脆弱性処理

概要

OpenSSLは、主要な暗号化アルゴリズム、一般的に使用されるキーと証明書のパッケージ管理機能、SSLプロトコルを含む、強力なセキュアソケットレイヤー暗号化ライブラリであり、テストやその他の目的で豊富なアプリケーションを提供します。

この記事では、主にnginxWebサーバーでより強力なSSLを設定する方法について説明します。可能な場合はForwardSecrecyを実現するために、SSL / TLSプロトコルで脆弱なSSLv3以降のバージョンを使用せず、より強力な暗号スイートを設定し、HSTSとHPKPを同時に有効にします。

SSLセキュリティテスト検証Webサイト：https：//www.ssllabs.com/ssltest/

構成ファイルと対応するセキュリティオプションの説明

1）構成ファイルの場所。デフォルトのsslポートは443で、実際には必要に応じて変更できます。

Ubuntu / Debian：/etc/nginx/sited-enabled/yoursite.com

RHEL / CentOS：/etc/nginx/conf.d/nginx.conf

注：構成ファイルを変更する前に、ファイルまたは関連オプションをバックアップしてください。実稼働環境には特に注意してください。

2）リスク：

（1）BEAST攻撃とRC4アルゴリズム

暗号化アルゴリズムCBC暗号ブロックの暗号化モードを改ざんすることにより、暗号化されたトラフィックの一部を秘密裏に復号化することができます。

新しいバージョンのブラウザクライアントは、BEASE攻撃を軽減できます。すべてのTLS1.0暗号を無効にし、RC4のみを使用することをお勧めします。ただし、[RC4には攻撃を防ぐためのリストが増え続けています]（http://www.isg.rhul.ac.uk/tls/）それらの多くは理論と現実を交差させています。そして、これがNSAがRC4をクラックした理由であり、彼らはこれを「大きな進歩」と呼んでいました。

RC4を無効にすると、いくつかの結果が生じます。1.悪いブラウザを使用するユーザーは、代わりに3DESを使用します。3-DESはRC4よりも安全です。しかし、それはより高価であることを意味します。そのようなユーザーのために、サーバーはより高価になります。2. RC4は、BEAST攻撃を軽減できます。したがって、RC4を無効にすると、TLS 1ユーザーはAES-CBCに移動することで攻撃に対して脆弱になります（通常のサーバー側のBEAST「修正」はRC4を何よりも優先することです）。BEASTのRC4の欠陥は明らかにリスクよりも大きいと確信しています。実際、クライアント側の緩和策（chromeとFirefoxの両方で提供）BEASTはもはや問題ではありません。しかし、RC4が成長するリスクについては、時間の経過とともに暗号解読が表面的になります。

（2）FREAKアタック

FREAKは、Cryptographic Experts GroupによってINRIA、Microsoft Research、およびIMDEAで発見された中間者攻撃です。FREAKは「FactoringRSA-EXPORTKeys」です。この攻撃は、出力暗号スイートの暗号化キーの長さが512ビットを超えない限り、米国政府が暗号化ソフトウェアの海外での販売を禁止した1990年代にさかのぼることができます。

AppleのSecureTransportやOpenSSLなどの一部の高度なTLSクライアントにはバグがあることが判明しました。このバグにより、クライアントがRSAキーの出力レベルを必要としない場合でも、RSAキーの出力レベルを受け入れるようになりました。このバグの影響は非常に深刻です。クライアントが脆弱で、サーバーが出力RSAをサポートしている場合、第三者がアクティブな攻撃者を介して攻撃し、接続の品質を低下させる可能性があります。

サーバーの2つの部分が受け入れる必要のある「RSA出力レベル」攻撃は次のとおりです。

（3）MITM攻撃：

プロセスは次のとおりです。

在客户端的Hello消息中，它请求一个标准的“RSA”密码套件。
MITM攻击者改变这个消息为了得到“RSA的输出”.
服务器返回一个512位的RSA输出密钥，并用它的永久密钥签名。
由于OpenSSL和SecureTransport存有bug，客户端就接受了这个弱密钥。
攻击者分析RSA模块为了恢复正在通信时RSA的解密密钥。
当客户端把加密的“预备主密钥”发送给服务器时，攻击者现在可以解密它从而得到TLS的“主密钥”。
从现在起，攻击者就可以看到明文了，并且可以注入任何他想的东西。

このページでは暗号スイートが提供されていますが、パスワード出力レベルをサポートしています。OpenSSlが最新の更新バージョンであり、クライアントが最新のソフトウェアを使用していることを確認してください。

（4）ハートブリード（心臓の出血）

Hearbleedは、2014年4月にOpenSSL暗号化ライブラリで発見されたセキュリティの脆弱性です。TransportLayer（TLS）プロトコルの実装で広く使用されています。Heartbleedは、サーバーやクライアントなど、脆弱なOpenSSLが使用されているかどうかに関係なく使用できます。これは、DTLSハートビート拡張機能（RFC6520）での不適切な入力確認（境界チェックがないため）が原因であるため、この脆弱性の名前は「ハートビート」です。この脆弱性は、許可されている以上の再読み取りバッファーとして分類されます。読み出す。

Heartbleedの影響を受けるOpenSSLのバージョンはどれですか？

異なるバージョンの状況：

OpenSSL 1.0.1 到 1.0.1f (包括) 受攻击。
OpenSSL 1.0.1g不受攻击。
OpenSSL 1.0.0的分支不受攻击。
OpenSSL 0.9.8 的分支不受攻击。

OpenSSLは2011年12月にこの脆弱性を発見し、2012年3月14日にOpenSSL1.0.1がリリースされるまで対策を講じませんでした。2014年4月7日にリリースされたOpenSSL1.0.1gは、この脆弱性を修正しました。

OpenSSLを更新することにより、この脆弱性によって引き起こされる攻撃を回避できます。

（5）SSL圧縮（犯罪攻撃）

一般的に、犯罪攻撃はSSL圧縮を使用して魔法を実行します。nginx1.1.6 + / 1.0.9+ではSSL圧縮がデフォルトで無効になっています（openssl 1.0.0+が使用されている場合）。

nginxまたは他の以前のバージョンのOpenSSLを使用していて、ディストリビューションでこのオプションが元に戻らない場合は、ZLIBをサポートしていないOpenSSLを再コンパイルする必要があります。これにより、OpenSSLを使用するためのDEFLATE圧縮方式の使用が禁止されます。その場合でも、通常のHTMLDEFLATE圧縮を使用できます。

（6）SSLV2およびSSLv3

SSL v2は安全ではないため、無効にする必要があります。SSL v3を無効にすることもできます。TLS1.0がダウングレード攻撃を受けた場合、攻撃者がSSL v3の使用を強制的に接続できるようにすることができるため、「転送秘密」が無効になります。

この構成ファイルを再度編集します。

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

プードル攻撃とTLS-FALLBACK-SCSV

SSLv3は、「POODLE」脆弱性の悪用を許可します。これは、SSLv3を無効にする主な理由の1つです。Googleは、SSLの強制的なダウングレードを防ぐために、TLSFALLBACKSCSVと呼ばれるSSL / TLSの拡張機能を提案しています。以下は、アップグレード後に自動的に有効になるOpenSSLのバージョンです。

OpenSSL 1.0.1 有 TLSFALLBACKSCSV 在 1.0.1j 及更高的版本.
OpenSSL 1.0.0 有 TLSFALLBACKSCSV 在 1.0.0o 及更高的版本.
OpenSSL 0.9.8 有 TLSFALLBACKSCSV 在 0.9.8zc 及更高的版本.

（7）暗号スイート

Forward Secrecyは、永続キーが漏洩した場合にセッションキーの整合性を保証します。PFSは、セッションごとに新しいキーの派生を実行することでこれを実現します。

これは、秘密鍵が危険にさらされると、SSLトラフィックレコードの復号化に使用できないことを意味します。

暗号スイートは、Diffie-Hellman鍵交換を一時的に使用してPerfect ForwardSecrecyの形式を提供します。それらの欠点は、それらが高価であるということです。これは、楕円曲線の変化を使用することによって改善できます。

eg1：

ssl_ciphers 'AES128+EECDH:AES128+EDH';

eg2：Mozilla Foundationから、下位互換性（IE6 / WinXP）

ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

注：環境で古いバージョンのOpenSSLを使用している場合、使用できないパスワードは自動的に破棄されます。Nginxは常に完全な暗号スイートを使用し、OpenSSLがサポートする暗号スイートを選択できるようにします。暗号スイートの順序も非常に重要であり、通信で使用される優先度アルゴリズムを決定します。上で提案された暗号スイートの2つの例は、アルゴリズムが完全転送秘密を提供することを強調しています。古いバージョンのOpenSSLは、アルゴリズムの完全なリストを返さない場合があります。AES-GCMは一部のECDHEに非常に近く、UbuntuOpenSSLまたはRHELのほとんどのバージョンには存在しません。

新しいバージョンでは、次の情報に対してコマンドnmap --script ssl-cert、ssl-enum-ciphers -p 443host_ipを使用できます。

| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA-強い
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256-強い
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256-強い
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA-強い
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384-強い
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384-強い
| TLS_ECDHE_RSA_WITH_RC4_128_SHA-強い
| TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA-壊れています
| TLS_ECDH_anon_WITH_AES_128_CBC_SHA-壊れています
| TLS_ECDH_anon_WITH_AES_256_CBC_SHA-壊れています
| TLS_ECDH_anon_WITH_RC4_128_SHA-壊れています
| TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5-弱い
| TLS_RSA_EXPORT_WITH_RC4_40_MD5-弱い
| TLS_RSA_WITH_3DES_EDE_CBC_SHA-強力
| TLS_RSA_WITH_AES_128_CBC_SHA -強い
| TLS_RSA_WITH_AES_256_CBC_SHA -強い
| TLS_RSA_WITH_AES_256_CBC_SHA256 -強い
| TLS_RSA_WITH_AES_256_GCM_SHA384 -強い
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA -強い
シーン：A、B、C、Cが所属するクラスの要件を満たしていません

 MD5:   d272 52c0 b2ee 64ec ed34 07f1 643b 87a9
|_SHA-1: a098 6a65 4df2 cbb6 b859 e40a 953c bb91 c4f8 f639
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C

上記の出力では、weak、strongフィールド、weakはすべて40ビットで暗号化されており、strongはすべて128ビットを超えている必要があります。Nginx SSLでssl_ciphersが指定されていない場合、デフォルトで許可される暗号化アルゴリズムとプロトコルには、128ビット未満の対称暗号化キーを使用するアルゴリズムなど、安全でないことが証明されているアルゴリズムとプロトコルが含まれます。十分に安全で、128ビット未満の弱い暗号化アルゴリズムは無効になっているため、構成時にアルゴリズムを明確に指定する必要があります。

ssl_ciphers HIGH：！ADH：！MD5;

さらに、opensslはSSL / TLSプロトコル情報開示の脆弱性（CVE-2016-2183）を報告しました。これは、次のように説明されています。TLS
、SSH、IPSecネゴシエーション、およびその他の製品で使用されるDESおよびトリプルDES暗号の誕生日は約40億元。これにより、リモートの攻撃者がSweet32を介して攻撃できるようになります。公式の推奨事項はhttps://www.openssl.org/news/secadv/20160922.txtで、OpenSSL1.0.2ユーザーを1.0.2iにアップグレードします。さらに、DESベースのSWEET32攻撃を軽減するために、OpenSSL1.0.1およびOpenSSL1.0.2バージョンでは、DES暗号スイートが高暗号文字列から中暗号文字列に移動されました。

（8）優先ロジック

首先选择 ECDHE + AESGCM 密码。这些都是 TLS 1.2 密码并没有受到广泛支持。这些密码目前没有已知的攻击目标。
PFS 密码套件是首选，ECDHE 第一，然后 DHE。
AES 128 更胜 AES 256。有讨论是否 AES256 额外的安全是值得的成本，结果远不明显。目前，AES128 是首选的，因为它提供了良好的安全，似乎真的是快，更耐时机攻击。
向后兼容的密码套件，AES 优先 3DES。暴力攻击 AES 在 TLS1.1 及以上，减轻和 TLS1.0 中难以实现。向后不兼容的密码套件，3DES 不存在.
RC4 被完全移除. 3DES 用于向后兼容。 

（9）強制廃棄

aNULL 包含未验证 diffie - hellman 密钥交换，受到中间人这个攻击
eNULL 包含未加密密码(明文)
EXPORT 被美国法律标记为遗留弱密码
RC4 包含了密码，使用废弃ARCFOUR算法
DES 包含了密码，使用弃用数据加密标准
SSLv2 包含所有密码,在旧版本中定义SSL的标准,现在弃用
MD5 包含所有的密码，使用过时的消息摘要5作为散列算法

3）opensslでサポートされている暗号化アルゴリズム

（1）対称暗号化アルゴリズム

OpenSSLは、合計8種類の対称暗号化アルゴリズム方式を提供しました。パケット暗号化アルゴリズムの7つは、RC4の1つのストリーム暗号化アルゴリズムのみです。7つのブロック暗号化アルゴリズムはAES、DES、Blowfish、CAST、IDEA、RC2、RC5であり、これらはすべて電子コードブックモード（ECB）、暗号化ブロックリンクモード（CBC）、暗号化フィードバックモード（CFB）、および出力フィードバックモード（ OFB）一般的に使用される4つのブロック暗号暗号化モード。その中で、AESで使用される暗号化フィードバックモード（CFB）と出力フィードバックモード（OFB）のパケット長は128ビットですが、他のアルゴリズムは64ビットを使用します。実際、DESアルゴリズムは、一般的に使用されるDESアルゴリズムであるだけでなく、3つのキーと2つのキーの3DESアルゴリズムもサポートしています。

（2）非対称暗号化アルゴリズム

OpenSSLは、DHアルゴリズム、RSAアルゴリズム、DSAアルゴリズム、楕円曲線アルゴリズム（EC）を含む合計4つの非対称暗号化アルゴリズムを実装しています。

DHアルゴリズムの一般的なユーザーキー交換。

RSAアルゴリズムは、鍵交換とデジタル署名の両方に使用できます。

DSAアルゴリズムは通常、デジタル署名にのみ使用されます。

（3）情報ダイジェストアルゴリズム

OpenSSLは、MD2、MD5、MDC2、SHA（SHA1）、およびRIPEMDの5つの情報ダイジェストアルゴリズムを実装しています。SHAアルゴリズムには、実際には2つの情報ダイジェストアルゴリズムSHAとSHA1が含まれています。さらに、OpenSSLは、DSS標準で指定されている2つの情報ダイジェストアルゴリズムDSSとDSS1も実装しています。

4）DESアルゴリズムはNginxで無効になっています：

（1）opensslで現在サポートされているアルゴリズムを表示します：openssl暗号-V

その中で、Kxテーブルキー交換アルゴリズム：セッションキーのネゴシエーションに使用されます; Auテーブル検証アルゴリズム：サーバーのIDを検証するために使用されます; Enc対称暗号化アルゴリズム：暗号化されたメッセージ; Macダイジェストアルゴリズム：アンチメッセージ改ざん。nginxのデフォルト設定はHIGH：！aNULL：！MD5です。

（2）DES暗号化を無効にします。

nginx -tを実行して、現在のnginx構成ファイルの場所を確認し、変更します。nginx構成ファイルの暗号オプションアルゴリズムリストには、コロンで区切られた1つ以上の暗号オプションアルゴリズムリストが含まれています。感嘆符！は、このアルゴリズムが禁止されていることを意味します。そのため、ブラウザが安全でないアルゴリズムを使用すると、接続が自動的に禁止されます。

検証：nmapの-Pn --script SSL-CERT、SSL-列挙-暗号-p 443 HOST_IP


上述したように、TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA（secp256r1）とTLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA（DH 2048）_C3_RSA_WITH_RSA_WITHは、
これは私が設定していない別のサーバであるため、別のサーバでありますDES暗号化アルゴリズムを無効にした後、もう一度テストしたところ、効果は次のとおりです。

5）Nginxの他のセキュリティ構成

Nginx.confに次のオプションを追加して、SSLv3またはTLSv1ハンドシェイク中に暗号を選択してください。

ssl_prefer_server_ciphers on;
ssl_session_cache shared：SSL：10m;

HTTP Strict TransportSecurity

可能であれば、HTTP Strict Transport Security（HSTS）を有効にする必要があります。これは、HTTPS経由でのみサイトにアクセスするようにブラウザーに指示します。

HTTP公開鍵ピンニング拡張機能

HTTP公開鍵ピンニング拡張機能も有効にする必要があります。

公開鍵ピンニングとは、証明書チェーンのホワイトリストに公開鍵が含まれている必要があることを意味します。これにより、ホワイトリスト内のCAのみが* .example.comに署名でき、ブラウザに保存されているCAは署名できなくなります。
6）Forward Secrecy

Forward Secrecyの概念は単純です。クライアントとサーバーは信頼できるキーをネゴシエートし、セッションの終了後にそれを破棄します。サーバーのRSA秘密鍵は、クライアントとサーバー間で交換されるDiffie-Hellman鍵に署名するために使用されます。セカンダリマスターキーは、Diffie-Hellmanハンドシェイクから取得され、暗号化に使用されます。セカンダリマスターキーはクライアントとサーバー間の接続に固有であり、限られた時間だけ使用されるため、エフェメラル（短命）と呼ばれます。

Forward Secrecyにより、攻撃者がサーバーの秘密鍵を保持していても、過去のセッションを復号化することはできません。秘密鍵は、DH（Diffie-Hellman）ハンドシェイクに署名するためにのみ使用され、副マスター鍵は公開されません。Diffie-Hellmanは、サブマスターキーがクライアントとサーバーを離れたり、仲介者によって傍受されたりしないようにします。

すべてのnginxバージョンは、Diffiel-Hellmanにパラメーターを入力するときにOpenSSLに依存しています。残念ながら、これは、Diffiel-Hellman Ephemeral（DHE）が1024ビットの交換キーを含むOpenSSLのこの欠陥を使用することを意味します。2048ビットの証明書を使用しているため、DHEクライアントは非エフェメラルクライアントよりも弱い鍵交換を使用します。したがって、我々は強くDHEパラメータを生成する必要があり、実行します。
CDの/ etc / sslの/ certsの
opensslのdhparam -out dhparam.pem 4096
VI /etc/nginx/nginx.conf、書き込み：ssl_dhparamの/ etc / sslの/ certsの/ dhparam。 pem;このように、nginxはDHEキー交換にdhparam.pemを使用します。

7）該当するOCSP

OCSPは、オンライン証明書ステータスプロトコル、つまりオンライン証明書ステータスプロトコルと呼ばれます。

サーバーに接続するとき、クライアントは証明書失効リスト（CRL）を使用してサーバー証明書の有効性を検証するか、オンライン証明書ステータスプロトコル（OCSP）レコードを使用します。ただし、CRLの問題は、CRLアイテムのリストが増え続けており、継続的にダウンロードする必要があることです。

OCSPは、一度に1つのレコードしかフェッチしないため、より軽量です。ただし、副作用として、サーバーに接続するときに、OCSP要求をサードパーティのレスポンダーに送信する必要があります。これにより、遅延が増加し、障害が発生する可能性が高くなります。実際、OCSPレスポンダーはCAによって制御されます。信頼性が低いことが多いため、ブラウザーはタイムリーな応答を受信しないために失敗します。これにより、攻撃者がOCSPレスポンダーに対してDoS攻撃を実行して検証をキャンセルできるため、セキュリティが低下します。

解決策は、TLSハンドシェイク中にサーバーがキャッシュされたOCSPレコードを送信できるようにして、OCSPレスポンダーをバイパスすることです。この手法により、クライアントとOCSPレスポンダー（OCSPクローズド（OCSPステープリング）と呼ばれる）の間のやり取りが節約されます。

サーバーは、クライアントが要求したときにのみキャッシュされたOCSP応答を送信し、CLIENTHELLOのstatus_requestTLS拡張を介してサポートを宣言します。

ほとんどのサーバーは、最大48時間OCSP応答をキャッシュします。サーバーは定期的にCAのOCSPレスポンダーに接続して、最新のOCSPレコードを取得します。OCSPレスポンダーの場所は、署名された証明書の[Authority InformationAccess]フィールドから取得されます。

コマンド检的：
openssl s_client -connect ffis.me:443 -servername ffis.me -status -tlsextdebug </ dev / null 2>＆1 | grep-i「OCSP応答」

# 开启 OCSP Stapling，开启后服务器在TLS握手时发送事先缓存的OCSP响应，用户只需验证该响应的有效性而不用再向数字证书认证机构（CA）发送请求
ssl_stapling on;
# 启用或禁用服务器对OCSP响应的验证
ssl_stapling_verify on;
# 证书的签发机构的ca证书，我的Let's Encrypt是acme.sh自动获取的证书，ca证书目录为：/root/.acme.sh/ffis.me/ca.cer
ssl_trusted_certificate /usr/local/nginx/conf/ssl/ffis.me_ca.cer;
# 添加resolver解析OSCP响应服务器的主机名，valid表示缓存。这里添加是为了解决DNS污染问题。
resolver 8.8.8.8 8.8.4.4 223.5.5.5 valid=60s;
# 网络超时时间
resolver_timeout 2s;

問題は残ります。OCSPクエリはサーバー側で実装されます。これにより、ブラウザーはOCSP検証を実行できなくなり、アクセス速度に影響します。
ただし、OCSP応答キャッシュはプリロードされませんが、非同期でロードされます。Nginxの起動後、クライアントがアクセスすると、NginxはOCSP応答の要求を開始し、ローカルにキャッシュします。OCSP応答キャッシュの有効期限が切れると、アクティブに更新されませんが、クライアントが非同期でトリガーされた更新にアクセスするのを待ちます。
これにより、常にOCSP応答キャッシュを通過しなかった訪問が数回あり、アクセス速度が遅くなりました。

[OCSPの脆弱性]：
OpenSSL OCSPステータス要求拡張機能に重大な脆弱性があり、悪意のあるクライアントがサーバーのメモリを使い果たします。この脆弱性を悪用することにより、デフォルト構成のサーバーは、契約がネゴシエートされるたびにOCSP IDメモリのセクションを割り当てることができます。ネゴシエーションを繰り返すと、サーバーがOCSPで構成されていない場合でも、サーバーのメモリが無限に消費される可能性があります。理論的には、OCSP IDは最大65,535バイトになる可能性があり、攻撃者はサーバーのメモリ消費量が毎回64K近くになることを再考し続けることができます。ただし、実装に関しては、OpenSSL 1.0.2バージョンでは、ClientHelloの長さは16,384バイトに制限されているため、大企業がサーバーのメモリ消費量を約16Kにすることができます。ただし、最新バージョン1.1.0では、ClientHelloの長さの制限が131,396バイトに引き上げられているため、バージョン1.1.0を使用するサーバーの場合、メモリ消費量は毎回ほぼ64Kになります。

影響を受けるバージョン：

OpenSSL0.9.8hから0.9.8v

OpenSSL1.0.1から1.0.1t

OpenSSL1.0.2から1.0.1h

OpenSSL 1.1.0

影響を受けないバージョン：

OpenSSL 1.0.1u

OpenSSL 1.0.2i

OpenSSL 1.1.0a

解決策：攻撃されないように、最新バージョンにアップグレードしてください。秘密鍵や証明書をキャンセルする必要はなく、攻撃者は秘密鍵を盗むことはできません。https://www.openssl.org/source/

5）Nginxセキュリティ構成の例

server {
    
    
 
  listen [::]:443 default_server;
 
  ssl on;
  ssl_certificate_key /etc/ssl/cert/blue.pem;
  ssl_certificate /etc/ssl/cert/ca-blue.pem;
 
  ssl_ciphers 'AES128+EECDH:AES128+EDH:!aNULL';
 
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_session_cache shared:SSL:10m;
 
  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 8.8.4.4 8.8.8.8 valid=300s;
  resolver_timeout 10s;
 
  ssl_prefer_server_ciphers on;
  ssl_dhparam /etc/ssl/certs/dhparam.pem;
 
  add_header Strict-Transport-Security max-age=63072000;
  add_header X-Frame-Options DENY;
  add_header X-Content-Type-Options nosniff;
 
  root /var/www/;
  index index.html index.htm;
  server_name raymii.org; 
}