web-dev-qa-db-ja.com

SSLリクエストを処理するようにWebサイトを強制すると、SSLstripが機能しなくなるだけですか？

HSTSでWebサイトを実行すると、攻撃者がKRACKを使用してWebサイトをダウングレードし、HTTPリクエストを処理するのを防ぐことができることを理解しています。

WebサーバーがHSTSをサポートしていない場合はどうなりますか？

IISには、SSL要求のみを要求できるWebサイトの設定があります。

攻撃者がSSLstripを使用してHTTPSをHTTPにダウングレードするのを防ぐのに十分ですか？ WebサーバーがHTTPS以外のトラフィックの処理に失敗すると思いますか？

tlsiissslstripkrack
2
cflyer

攻撃者がSSLstripを使用してHTTPSをHTTPにダウングレードするのを防ぐのに十分ですか？

番号。

WebサーバーがHTTPS以外のトラフィックの処理に失敗すると思いますか？

番号。

MitMはサーバーとhttpsを話し、クライアントとhttpを話します。

sslstripに対する唯一の実際の防御策はHSTSです

https://www.tbs-certificates.co.uk/FAQ/en/hsts-iis.html によると、IIS with [カスタムHTTP応答ヘッダーの追加]ダイアログ。

注：HSTSは、httpsへの最初のアクセスが成功した後にのみアクティブになります。最初のアクセスを保護するには、プリロードメカニズムを使用できます。 https://hstspreload.org/ ですが、後で無効にすることはできません。

3
Tom

この場合、HTTPSのみを使用しても保護されません。この 他の質問 は、理由を説明するのに役立ちます。つまり、攻撃者がクライアントにHTTP経由の通信を強制できる場合、攻撃者はあなたとクライアントの間を行き来してリレーとして機能し、HTTPでクライアントと、HTTPSでサーバーと通信することができます。

クライアントにサーバーへのHTTP呼び出しを絶対に試行させない方法があったらいいのですが、ありがたいことにHSTSを使用できます。しかし、典型的なHSTS構成は、攻撃を試みる前に安全な接続を確立できる場合にのみ、ユーザーを保護します。これは、HSTSが Trust On First Use 、またはTOFUモデルに依存しているためです。攻撃の前にクライアントのマシンでHSTSヘッダーを取得できる場合、クライアントは安全です。攻撃者が既に配置されている場合、HSTSヘッダーを取り除き、クライアントへの攻撃を続行できます。

HSTSヘッダーをプリロードすると、これを回避できます。 HSTSを事前ロードするということは、ドメインをブラウザーベンダーに登録すると、サーバーへのセキュリティで保護されていない接続を許可しないようにブラウザーがハードコーディングされます。これは、クライアントがサーバーにHTTPリクエストを送信しないため、SSLstrip攻撃を非常に困難にします。 注意してください。HSTSプリロードには独自のリスクセットがあります。これ その他の質問 には、HSTSおよびHSTSプリロードへの優れた参照があります。質問を読んでくださいと詳細のすべてのトップ3の答え。

トムが回答で述べたように、カスタムHTTP応答ヘッダーを使用してHSTSを設定できます。 Web.Configファイルで行うこともできます。

<configuration>
    <system.webServer>
        <httpProtocol>
            <customHeaders>
                <add name="Strict-Transport-Security" value="max-age=31536000" />
            </customHeaders>
        </httpProtocol>
    </system.webServer>
</configuration>

注：これには、プリロード属性は含まれません。また、必要なincludeSubDomains属性も除外されます。繰り返しますが、これらの属性の両方に非常に注意してください。単純にそれらを実装しないでください。

3
Taul