httpをhttpsにリダイレクトせずに、サイト全体を強制的にhttps

14

サイト全体をhttpsにする方法を調査しているときに、たくさんの議論がありました。ほとんどの答えは、httpをhttps（.htaccessファイル）にリダイレクトすることでした。これは、同じジョブを2回（2つの要求）行うのは良くないため、良くありません。また、「真ん中の男」が最初にhttpを使用し、自分のサイトがhttpsに直接アクセスするようにします。サイト全体をhttpsにする別の方法はありますか？たとえば、ユーザーがexample.comに入力すると、そのexample.comは、httpまたは他の何かから先にリダイレクトすることなく、自動的にhttpsになりますか？

http  https 
— マルコ・タンブリック
ソース
人をhttpsにリダイレクトしたくない場合、代わりに何をしたいですか？
— マイケルハンプトン
@MichaelHamptonたぶん私は初心者の質問をしているかもしれませんが、私は実質的にhttpを「削除」したいのですが、存在するのはhttpsだけです。または、これが不可能な場合、セキュリティに十分であればリダイレクトを使用できます。リダイレクトhttp-> httpsは、httpのままであり、リダイレクト中にトラフィックがインターセプトされる可能性があるため、あまり良くないと聞きました。
— マルコタンブリック14
HTTP 301パーマネントリダイレクトはあなたの友達です。有効期限の設定を忘れないでください。
— マルセル14
httpを削除するだけです。しかし、その後、ユーザーはhttps：//を入力していない場合、接続拒否メッセージのみを受け取ります。一部のサイトでは、これはセキュリティが高いため、これが優れています。利用可能なhttpバージョンがある場合、最初のリクエストが暗号化されずにcookieが送信される可能性があります。会社のメールシステムなどの場合はhttpsのみ+ユーザートレーニングは問題ありませんが、一般的なサイトでは多くの訪問者を失う可能性があります。
— ジョセフは、モニカを復活させる14
AfaikはHTTP2で可能になりましたが、SSLストライピング攻撃を回避することはできません（以下の回答で説明します）。
— peterh -復活モニカ

回答:

20

いいえ。訪問者のブラウザに魔法のように正しいプロトコルを選択させることはできません。リダイレクトはそれを行う方法です。

— ジェニー・D
ソース
1
この答えをさらに拡張するには、Mark Hendersonが指摘しているように、URL書き換えと301ステータスコードの使用を検討してください
— Ryan Ries 14
— マルセル・
22

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Securityを使用すると、サーバーはHTTPS経由でのみドメインにアクセスする必要があることを示すことができます。これは後続のリクエストにのみ適用されるため、最初にHTTPがロードされますが、誰かが明示的にHTTPを入力した場合でも、将来のリクエストはHTTPSをロードします。

IEはまだサポートしていませんが、他のすべてのメジャーはサポートしています。

— シージャオズ
ソース
それでも、最初の要求に対する保護はありません。
— ジェニーD 14
3
@JennyD私はまさにその答えで正確に言った。
— ceejayoz 14
@JennyD「保護」とはどういう意味ですか？MiMは、ローカルDNS /ルーティングを混乱させ、ドメイン全体を偽造しない限り、http-> httpsリダイレクトに対して何もできません。その場合、サーバーにアクセスすることはないため、実際に何をするかは重要ではありません。
— レッドアラート14
2
@JennyDまあ、HSTSはあなたの投稿よりも優れたソリューションであり、「リダイレクトがそれを行う方法です」と言っています。リダイレクトはいつでもMITMできます。HSTSを使用したリダイレクトは、ユーザー+ブラウザー（またはヘッダーにある有効期限）ごとに年に1回しかMITMできません-それ以外の場合は要求されません。
— ceejayoz 14
1
@MarkoTamburic 2つを組み合わせることができない理由はありません。
— ceejayoz
7

他の人が言ったように、ユーザーに正しいプロトコルを選択させることはできません。しかし、ユーザーがHTTPを使用しようとする場合、どうすればよいですか？あなたとクライアントの間に座っている攻撃者がリダイレクトを傍受する可能性があるため、リダイレクトも不十分であり、クライアントはそれを見ることはありません。クライアントは引き続きプレーンHTTPを送信し、攻撃者はサーバーからSSLレイヤーを除去します（SSLストリッピング攻撃）。

それを防ぐ唯一の確実な方法は、HTTPをまったく提供しないことです。ポート80で応答しないでください。ただし、HTTPSで再試行するようユーザーに指示するプレーンテキストページを提供する場合を除きます（ただし、攻撃者が操作できるリンクは提供しません）。これにより、ユーザーhttps://はブラウザに強制的に入力されるため、SSLを使用して接続を開始し、MITM攻撃を防ぐことができます。

— アンドリュー・シュルマン
ソース
3
ただし、ほとんどのユーザーはを入力しないため、これはトレードオフhttps://です。代わりに、彼らは「ハァッ、サイトが壊れている」と言って去ります。最善のシナリオはwww.example.com、HTTPとHTTPSの両方に応答することですが、HTTPS admin.example.comのみのようなものでアプリ自体を実行することです。
— ceejayoz 14
同意した。実際には、これを行う人はほとんどいません。
— アンドリューシュルマン14
私はそれがどのようにこれ以上のMiMプルーフになるのか本当に見ていません。中間の男性がハイパーリンクを変更して別の場所を指すことができる場合、それはユーザーの着信パケットを制御していることを意味します。彼は、サイトがどのように見えるかに関係なく、自分のサイトに簡単にリダイレクトしたり、必要なハイパーリンクを追加したりできます。
— レッドアラート14
ただし、理論的には、クライアントがSSLを使用して接続を開始した場合はそうではありません。
— アンドリューシュルマン14
3
それは本当です-しかし、クライアントがSSLで開始する場合、OPは問題ありません。彼の問題は、彼らがSSLなしで開始するときであり、それを積極的に妨害しているMiMがいる場合、それらをSSLに確実に到達させる方法はありません。
— レッドアラート14
1

ceejayozには、ここで具体的に述べた攻撃を防ぐための最良の答えがありますが、ここで多くの人々が見逃していることも指摘したいと思います。永続的な301リダイレクトを行いたい。これにより、クライアントは新しいアドレスに対してさらにリクエストを行うようになります。したがって、はい、誰かが間違ったURLを入力した場合、2つのリクエストを行いますが、将来的には、優れたクライアントはそのURLへのリクエストを検出し、代わりに無駄なリクエストを防ぐために正しいリクエストを行うことになっています。問題は、これはその正確なURL専用であるということです。HSTSは、「次のn秒間、このドメインからの非セキュア接続も許可しない」と言うことで、このスキームを改善しています。

ユーザーは、安全でない場所にある機密サイトにアクセスしないでください。特に、安全でない場所にサインアップするべきではありません。これらは基本的なユーザーセキュリティプリンシパルであり、「信頼できないソースからの添付ファイルを開かないでください」と同様に教える必要があります。これは、訪問されたことのないサイトのMiM攻撃を防ぐための最良の答えです。

補足として、一部のブラウザーは、特定の既知のサイトが常にHSTSを使用していると言うことで、これを改善しています。残念ながら、このリストに簡単に自分を追加することはできません。

さらに読む：http : //coderrr.wordpress.com/2010/12/27/canonical-redirect-pitfalls-with-http-strict-transport-security-and-some-solutions/

http://dev.chromium.org/sts

— クロウ
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.