httpsを別のhttpsにリダイレクトする

私はこの質問にグーグルで取り組んできましたが、皮肉なことに、具体的な答えが見つかりません。私は過去にこの質問に自分で答えましたが、今は自分の説明を思い出せません。

年に数回、誰かが私にこれをするように頼みます。これを説明するある種の立派な記事を紹介したいと思います。

https://www.example.com/のURLを取得し、トラフィックをhttps://www.example2.com/にリダイレクトしたいです。

これは技術的には可能だと思いますが、望ましくありません。この方法の何が問題になっていますか？ブラウザを別のサイトにリダイレクトしているので、ブラウザにセキュリティポップアップが表示されますか？誰もがこれを説明するいくつかの立派なドキュメントへのリンクを提供できますか？

これを行うには、両方のサイトに有効なSSL証明書が必要です。この方法では、ブラウザはセキュリティポップアップを表示しません。ただし、両方のサイトが同じサーバーに存在する場合、両方のドメインを異なるIPアドレスからホストする必要があります。

Webサーバーは、HTTP要求の「Host」ヘッダーを調べて、サービスを提供する必要があるサイトを確認します。SSLネゴシエーションはHTTPリクエストが送信される前に行われるため、その時点でWebサーバーはどのWebサイトを表示するかを判断できません。常に同じ証明書をブラウザに送信します。

これを回避するには2つの方法があります。

• * .example.comのワイルドカード証明書があるため、すべてのサブドメインが同じ証明書を共有できます。
• 各SSLサイトを異なるIPアドレスで実行します。このように、Webサーバーは、着信接続を受信したIPアドレスを検査することにより、ブラウザーに送信できるSSL証明書を認識します。

同じネットワークアダプターに複数のIPアドレスを接続することは完全に可能であることに注意してください。IPアドレススペースで使用可能な2番目のIPアドレスが必要なだけです。

更新：現在、単一のIPで複数のSSLサイトを実行できます。これを有効にするには、WebサーバーでSNIサポートを構成します。最新のブラウザ（Windows XPおよびAndroid 2を除く）は、これをサポートしています。

私はこれを試したことがないので、具体的な経験から話をしませんが、うまくいくはずです。ホスト名はHTTPヘッダー内で暗号化されるため、https：//www.example.comの有効なSSL証明書が必要になります。これにより、サーバーは、復号化されるまでリダイレクトする必要がなくなります。その後、通常のHTTP要求と同じようにリダイレクトする必要があります。

なぜこれが望ましくないのでしょうか？

例として、Big BankとLittle Bankは両方ともhttpsでサイトを運営し、顧客に安心感を与えています。ビッグバンクはリトルバンクを買います。ある時点で、IT担当者はhttps://www.littlebank.comからhttps://www.bigbank.comへのリダイレクトを設定します。これは、httpsからhttpsにリダイレクトする正当な理由です。

これでうまくいくはずです。

私があなたのために現れるかもしれない現在の応答に存在すると思う1つの切断は、これらの状況のいずれかで、真のリダイレクト（つまり、ブラウザはwww.example2.comにリポイントされます）がうまくいくが、これをマスクすると現実には、あなたがwww.example2.comにそれを送信した際に、ブラウザのstillthinksは、それがwww.example.comで指摘されるように、これはあなたがユーザーを偽装しようとする可能性があるため、あなたが正確にセキュリティ警告が表示される場所です。

短いバージョンは通常のリダイレクトで問題ありませんが、アドレスマスキングにより、多くの説明を行うことができます。

ご覧のように、この問題はトランスポート層で解決できます。example.comの192.168.0.1を指すDNS Aレコードがあるとします。あなたが入力するとhttps://example.comのブラウザでお使いのPCは、ポート443上のいくつかのプロセスのリッスンが同時にサーバーが（に何をしようとされていない場合、IP 192.168.0.1、とサーバーへのTCP接続を確立しましたSSLネゴシエーションの開始など、このTCPセッションを介して送信されるデータの詳細を取得します）192.168.0.2（DNSを指しているexample2.comを持つ他のサーバーへのTCP接続を確立します。最初のサーバーにインストールされたHAプロキシLinux utulityは、そのような構成：

defaults
        log    global
        mode    tcp
        retries 2
        option redispatch
        option tcplog
        option tcpka
        option clitcpka
        option srvtcpka
        timeout connect 5s      
        timeout client  24h     #timeout client->haproxy(frontend)
        timeout server  60m

listen front443 192.168.0.1:443
    server back443 192.168.0.2:443

ただし、example2.com WebサーバーがCN = example2.comおよびSAN = example.comなどのSSL証明書を表示しない限り、これによりSSL証明書エラーが発生します。

または、ユーザーからのperstective example.comおよびexample2.comが192.168.0.1に解決されるときに、DNS slpit horizo​​nをセットアップできます。