web-dev-qa-db-ja.com

HTTPSサーバーが誤って秘密キーを漏洩する可能性はありますか？

HTTPSのWebサイトがSSL証明書の秘密キーを漏洩する既知のケースはありますか？悪質なWebサイト管理者が、証明書チェーンの一部として秘密鍵を送信するようにサイトを誤って設定することは技術的に可能ですか？

tlscertificatescryptographywebserver
24
John Blatz

HTTPSのWebサイトがSSL証明書の秘密キーを漏洩する既知のケースはありますか？

はい- Heartbleed バグには、次のようなHTTPサーバーからのメモリリークが含まれていました。

跡形を残さず、外から攻撃しました。特権情報や資格情報を使用せずに、X.509証明書に使用されている秘密鍵を自分から盗むことができました...

そのようなバグは別として、

技術的に悪意のあるWebサイト管理者が、証明書チェーンの一部として秘密キーを送信するようにサイトを誤って設定することは可能ですか？

承知しました。 SSLCertificateChainFileなどで間違ったファイルを指定すると、Boom！秘密鍵があります。

@duskwuffがコメントで指摘しているように、これに対する保護策があります。 ApacheもNGINXも、証明書ファイルに含まれているキーPEMを送信しません。彼らは静かにそれを取り除きます（私は賭けますが、私が提案したことを行った人々がいくつかのイベントを実行した後に機能するように配置された保護です）。

不正なWebルートとゆるい権限または過剰なWebサーバー特権を組み合わせたその他の設定ミスもキーを漏らしますが、これらの設定ミスはありふれたものであり、極端なものです（たとえば、本当に悪いことを壊そうとしている必要があります）。

そうすることは推奨されません。

38
gowenfawr

はい、誤設定またはまだ不明な誤設定を介して。 @gowenfawrの回答の内容は繰り返さない。

余談ですが、キーを直接リークすることはありませんが、攻撃者が通信の一部を解読できる可能性のある、誤った設定がいくつかあることを付け加えておきます。 TLS 1.3への取り組みの一部は、特定の暗号およびその他の潜在的に安全でない構成のサポートを削除することでこれを軽減することを目的としています（ https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/ ）。

同様に、機密性が失われる可能性のあるものは他にもあります。 DROWN（ https://drownattack.com/ ）と呼ばれるSSL v2の脆弱性など、以前はSSL v2は安全でないことがわかっていましたが、多くのインストールでは互換性の理由で有効になっています。

理想的ではありませんが、これにより、同じキーまたは証明書を使用していても、パディングOracleを介してSSL v2を実行しているサーバーからセッションキーを抽出する可能性が生じ、同じ証明書を使用してTLS 1.2サービスのコンテンツが公開されました（後で被害者とサーバーの間の多数の接続を観察します）。

DROWNは、SSLv2を単にサポートすることは、現代のサーバーとクライアントにとって脅威であることを示しています。攻撃者は、SSLv2をサポートし、同じ秘密鍵を使用するサーバーにプローブを送信することにより、最新のクライアントとサーバー間の最新のTLS接続を解読できます。

キーを直接漏らすという観点から、誤って構成されたWebサーバーで、またはディレクトリトラバーサル（または同様の）問題を介して秘密キーを提供することもできます。

6
richard

Traefikに、APIエンドポイントがSSL証明書（CVE-2018-15598）の秘密鍵を漏えいさせる欠陥が発見されました。

https://Twitter.com/edoverflow/status/1031267058615508994

enter image description here

1
EdOverflow

HTTPSのWebサイトがSSL証明書の秘密キーを漏洩する既知のケースはありますか？

厳密に言うと、秘密鍵には権限が必要ですdr--------、root:root。したがって、ルートユーザーのみが証明書を読み取ることができます。これが正しく設定されておらず、Webサーバーが秘密鍵にアクセスできる場合、Webサーバーなどの一部の状況ではセキュリティが侵害されます。次に、秘密鍵がWebサーバーによって無意識のうちに「漏らされている」ことがわかります。もちろん、これは秘密鍵への読み取りアクセス権を持つすべてのプログラムに適用されます。

技術的に悪意のあるWebサイト管理者が、証明書チェーンの一部として秘密キーを送信するようにサイトを誤って設定することは可能ですか？

構成により、Apache 2を使用しました。したがって、私のWebサーバー構成の1つには次のものが含まれます。

    SSLCertificateFile /etc/Apache2/ssl/safesploit.com.cert.pem
    SSLCertificateKeyFile /etc/Apache2/ssl/safesploit.com.key.pem
    SSLCertificateChainFile /etc/Apache2/ssl/fullchain.pem

したがって、「不正な管理者」が秘密鍵をフルチェーン内に配置することについての懸念を理解していますが、Apacheがこのタイプの構成を受け入れるように変更されていない限り、Apache 2 Vanilla内では不可能です。

コンテキスト：

  • 公開鍵-r--r--r--ルートルート
  • 秘密鍵-r -------- root root
1
safesploit