SSLストリップを使用するためにHTTPからHTTPSにキャッシュされた301リダイレクトをバイパスする
私はペンをしています。 HSTSが実装されていないHTTPS（443）サーバーでのテスト（応答にHSTSヘッダーがなく、アドレスがChrome HSTSプリロードリストにない）。
問題は、私のシナリオでは、ユーザーが以前にWebサイトにアクセスしたことがあり、最初のHTTP（80）要求応答がChromeにキャッシュされていることです。
ここで、ユーザーがtargetaddress.comブラウザは自動的にキャッシュされたリダイレクトを取得します（301-HTTPからHTTPSへlocation=https://targetaddress.com）SSLstripを無効にします。
これに対する私の回避策は、クライアント側の443ポートをブロックすることでした。そのため、ユーザーはターゲットに接続できず、接続を復元しようとして、手動でブラウザーのキャッシュ/履歴をクリアします。その後、SSLstripはHTTPリクエスト（301リダイレクト）レスポンスを傍受/改ざんするため、効果的です。
ポート443をブロックする以外に、これを行う他のより良い方法はありますか？
キャッシュされたリダイレクトは次のとおりです。
http://targetaddress.com/
HTTP/1.1 301 Moved Permanently
Date: Wed, 23 Dec 2015 18:31:19 GMT
Server: Apache
Location: https://www.targetaddress.com/
Content-Length: 237
Content-Type: text/html; charset=iso-8859-1
ブラウザを作成できる場合は、http://targetaddress.com/whateverにリクエストを送信します。 /whateverのキャッシュされた応答はなく、/に対してのみキャッシュされるため、ブラウザーはデフォルトでHTTPSではなくプレーンなHTTP要求を行います。
これはいくつかの方法で実現できます。 1つの方法は、ブラウザとプレーンHTTPを介してアクセス可能なany Webサイトの間でMITMを実行し、<img>タグを挿入することです。もう1つの方法は、ソーシャルエンジニアリングを介してユーザーにアドレスバーにtargetaddress.com/whateverを入力させることです。
ブラウザがターゲットドメインにクリアテキストリクエストを送信するとすぐに、MITMがゲームに勝利しました。
HTTPにより、クライアントはエンティティに対してアクションを実行できます。実行されるアクションは、リクエストで指定されたHTTPメソッドに依存します。アクションが実行されるエンティティは、[〜＃〜] url [〜＃〜]リクエストで指定されます。
異なる[〜＃〜] url [〜＃〜]は同じエンティティを参照できますが、ブラウザはこれを認識しません。ブラウザがHTTP応答をキャッシュする場合、指定された[〜＃〜] url [〜＃に対してキャッシュします〜]。
http://www.target.com/は[〜＃〜] url [〜＃〜]です。 http://target.com/は別のものです。 http://www.target.com/whateverはまた別のものです。 http://www.target.com/?も同様です。
ここで、ブラウザにhttp://www.target.com/のキャッシュされたエントリがあるとします。上記にリストされている他の[〜＃〜] url [〜＃〜]のいずれかが存在することを意味しますか？いいえ、違います。
したがって、質問に戻り、HTTPポートでWebアプリケーションによって永続的なリダイレクトが返された場合にブラウザにプレーンテキスト要求を送信させることは、[〜を作成することの問題です。 ＃〜] url [〜＃〜]これはキャッシュエントリと一致せず、ユーザーにこれにアクセスするように仕向けます[〜＃〜] url [〜＃ 〜]。
これが機能することの証明：
127.0.0.1 - - [13/Apr/2016:10:01:17 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:01:35 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:02:10 +0200] "GET /whatever HTTP/1.1" 301 234 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:02:36 +0200] "GET /whatever HTTP/1.1" 301 234 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:08:16 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:08:25 +0200] "GET /? HTTP/1.1" 301 227 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
すべてに対して永続的なリダイレクトが構成されている場合でも、同じブラウザを使用して同じWebサイトに6つの（任意の数の）クリアテキストHTTPリクエストを送信できました。 （そして、いいえ、私はnotブラウザのキャッシュをクリアしました！）
永続的なリダイレクトを回避する他の明白な方法としては、ユーザーをだまして匿名ブラウザーモード（キャッシュなし）に切り替える、または別のブラウザーに切り替える（「IEでアプリにアクセスするときに問題が発生します。確認できますか？」）。
ターゲットユーザーにキャッシュをクリアしてもらうための実用的な方法はいくつかありますが、これが最も簡単な解決策かもしれません。これは、特に技術以外のターゲットにとってはそれほど疑わしいことではないかもしれません。何年もの間、誰からもITの問題を解決するための頼りになる提案だったからです。
傍受のためにwifiホットスポットを実行/偽っている場合に最も簡単です。ユーザーが最初に接続するときに受け入れる必要がある「契約条件」ページを表示し、アクセスを許可しないで、「これはキャッシュの問題が原因である可能性があります。X、Y、Zを実行してキャッシュをクリアしてください」と言います。キャッシュをまったく理解していれば、セキュリティ機能としてキャッシュを考えている人はいません。ほとんどの人は無料のインターネットと引き換えに陽気にそれをクリアし、それからあなたは黄金です。
ポート443に対してsynfloodを実行してみてください。クライアントは接続できず、ポート80に失敗する可能性があります。
ただの免責事項ですが、私はこれを試していません。誰かがチャイムしたいですか？