誰かがHTTPS接続をサイトのHTTPバージョンにリダイレクトするのを妨げているのは何ですか？
誰かがARPスプーフィングまたはDNSポイズニング攻撃を行って、トラフィックを自分のWebサーバーにリダイレクトするとします。実際のサイトにSSL/TLS証明書がある場合、ハッカーがリダイレクトできないようにして、google.comを自分のサーバーにリダイレクトしますか？ WebサーバーはHTTPとHTTPSのどちらで接続するかを決定しませんか？また、DNSルックアップは、サーバーに接続する前に行われます。彼らはクライアントにHTTPSではなくHTTP経由で接続するように指示することはできませんか？
HTTPとHTTPSのどちらを使用するかはクライアントが決定します。
ユーザーが直接http://example.com、攻撃者は単純にその接続を乗っ取り、中間者攻撃を実行する可能性があります。ユーザーが直接https://example.comの場合、攻撃者は何らかの方法でSSL/TLS接続を偽装する必要があります。ユーザーに無効な証明書の警告を表示せずにこれを行うには、攻撃者が認証局の秘密鍵にアクセスする必要があります。この状況は決して起こらないはずです。これがないと、ユーザーのブラウザが接続を拒否し、攻撃者がリダイレクトすることはできません。
Googleや他の多くのウェブサイトの場合、これらはHTTP Strict Transport Security（HSTS）ヘッダーを設定します。これにより、ユーザーのブラウザーは、たとえユーザーがそれを要求するか、Google自体がHTTP URLにリダイレクトします。ブラウザは自動的にURLをHTTPSに書き換えるか、リクエストを完全にブロックします。これにより、ほとんどのブラウザでユーザーが証明書の警告をクリックしてクリックすることもできなくなります。オプションはありません。
いいえ、DNSルックアップは、HTTPとHTTPSのどちらを介して接続する必要があるかをクライアントに通知しません。ブラウザは次のことを決定します。HTTPURLを入力するとポート80でTLSなしで要求し、HTTPSを入力するとポート443でTLSを使用して要求します。したがって、決定するのはサーバーでなくクライアントです。
サーバーがプロトコルを介してリクエストを受け取った場合、300ステータスコードとロケーションヘッダーで応答することでリダイレクトを発行することはできません。ただし、元の要求がHTTPSを介している場合、中間の男はその応答を送信できるように有効な証明書を必要とします。そして、それがあれば、そもそもHTTPにリダイレクトする必要はありません。
まず、OPが見逃した最大の問題は、SSL/TLSネゴシエーションが最初に発生することです。安全な接続がネゴシエートおよび検証された後のみ、HTTP通信が可能です。 HTTPSは大きな誤称です。完全に独立したSSL/TLSを介してのみ送信される単純な古いHTTPです。
実際のサイトにSSL/TLS証明書がある場合、ハッカーがリダイレクトできないようにして、google.comを自分のサーバーにリダイレクトしますか？
証明書が確認され、HTTPが実行される前にTLSが確立されます。証明書が間違っていると、最初に接続が確立されることはありません。リダイレクトの余地はありません。
WebサーバーはHTTPとHTTPSのどちらで接続するかを決定しませんか？
いいえ、クライアントは行います。ソケットを開いてHTTP要求をプレーンテキストで送信するか、ソケットを開いて完全なSSL/TLSネゴシエーションを実行してからHTTP要求を送信する。
また、DNSルックアップは、サーバーに接続する前に行われます。
はい。ただし、クライアントはDNS名に対して証明書をチェックします。そのため、DNSでGoogleの代わりにあなたになりすましますが、google.comに発行された証明書が必要です
彼らはクライアントにHTTPSではなくHTTP経由で接続するように指示することはできませんか？
いいえ。彼らはこれを行う機会を得ることはありません。
任意のドメインの任意の証明書を検証する認証局がたまたまある場合、それは大きな問題があるときです。関心のあるドメインに対してのみ行われるブラウザーによる証明書のピン留めの前に、他のすべての人がCAの動作に問題がないことに依存している必要があります。なりすましから変わります。むしろあるべきだ。