数年前まで、誰かが偽のワイヤレスAPをセットアップし、SSLStripのようなものを使用して被害者をGmail、Facebookなどの主要なWebサイトの安全でないバージョンに接続するように誘惑することを知っていました。これはまだ可能でした。しかし、今私が見ているように、これは主要なウェブサイトではもはや不可能です。数年前から何が変わったか。 HSTSはこれらのタイプのMitM攻撃をどのようにして防ぐのですか?
HSTSヘッダーは、ポリシーの有効期限が切れるまで、常に(HTTPではなく)HTTPS要求をドメインに送信するようブラウザーに指示することにより、MitM攻撃を阻止します。したがって、ユーザーがhttps://example.com
へのリンクをクリックしても、ヘッダーを尊重するブラウザーはhttp://example.com
にリクエストを送信します。
HSTSの背後にあるロジックは、2012年に [〜#〜] rfc [〜#〜] で定義されて以来変更されていません。変更された点は、現在ほとんどすべてのブラウザーが実装していることです。このポリシーを適用するのはブラウザであることを忘れないでください! 使用できます は、次のバージョンからそれをサポートするブラウザーを報告します。
(FirefoxとChromeがHSTSをサポートする方法は、私にとって謎です。)
したがって、それより古いブラウザを使用している人は、ヘッダーが設定されていても保護されません。これは、HSTSヘッダーの設定でSSLStripを以前は支援するために使用されなかったという印象を持つ理由を説明している可能性があります。
HSTSが役に立たないもう1つの理由は、ユーザーが攻撃前にそのページにアクセスしたことがないことです。ブラウザがヘッダーを見たことがない場合、それを強制することはできません。これは preloading で解決できます。
SSLStripはhttps
リクエストをプレーンhttp
に書き換え、保護を解除して盗聴と変更の両方を許可しました。
HSTS保護を備えたサーバーは、HTTPS要求にヘッダーを設定し、HTTPSを使用してそのサーバーにのみ接続するようブラウザーに要求します。
Strict-Transport-Security: max-age=31536000
この場合、1年間、ブラウザーはHTTPSでのみサーバーに接続し、すべてのリンクをHTTPS(反転SSLStrip)に書き換えます。
ただし、注意点があります。クライアントは、少なくとも一度はHTTPSを使用してサーバーにアクセスしている必要があります。クライアントがHTTP経由でのみ接続する場合でも、MiTMは発生する可能性があり、すべての要求を変更し、HTTPSリンクまたはリダイレクトをHTTPに戻すことができます。しかし、クライアントがHTTPSを使用してサーバーにアクセスするとすぐに、HSTS Cookieが設定され、SSLStrip MiTM攻撃は不可能になります。