影響を受けていないサーバーによってSSLが提供された場合のハートブリードの脆弱性？
*脆弱なバージョンのOpenSSLがサーバーにインストールされているが、そのサーバーがSSLサービスを提供していない2つのシナリオについてお聞きしたいと思います。
シナリオ1：ロードバランサーにSSL証明書をインストールし、その背後にIISサーバーのファームがあります。IISはHeartbleedの影響を受けず、ポート443はそこでスイッチを切りましたが、ロードバランサーが脆弱であることがわかりました。Heartbleedのどの側面が私たちに影響を与えますか？
シナリオ2：このシナリオでは、ロードバランサーは脆弱ではありません。この場合も、ロードバランサーには証明書がインストールされています。しかし、その背後には、PHPを実行しているサーバーのファームがあり、脆弱なバージョンのOpenSSLがインストールされて有効になっています。おそらく、別の拡張機能がそれを必要とするか、誰かが考えずに有効にしたためです。これらのサーバーでもポート443がオフになっています。 Heartbleedのどの側面が私たちに影響を与えますか？
私の理解に基づくと、シナリオ1では、サーバーとの間でネットワークを介してやり取りされるキーとデータが傍受されるリスクがあります。ただし、IISアプリケーションサーバーメモリの内容は、公開されるリスクはありません。
繰り返しになりますが、間違っている可能性がある私の理解に基づくと、シナリオ2ではリスクはありません。
誰かが私の仮定を検証または修正できますか？
Heartbleedを使用すると、TLS接続中に、[脆弱なバージョンの] OpenSSLが実行されているサーバーからメモリを公開できます。したがって、ハートブリードを悪用できるようにするには、サーバーが脆弱なバージョンのOpenSSLを実行している必要があります[〜＃〜]および[〜＃〜] TLS接続を受け入れます。
したがって、シナリオ1では、OpenSSLを実行しているサーバーであるため、ロードバランサーのメモリが公開されるリスクがあります。
シナリオ2では、これらのサーバーにTLS接続を確立できないようにシナリオが設定されていると仮定すると、脆弱性はありません。 TLS接続を確立できないため、脆弱なバージョンのOpenSSLを悪用することはできません。