Przekieruj https na inny https

Byłem w Google na to pytanie i jak na ironię nie mogę znaleźć konkretnej odpowiedzi. Odpowiedziałem na to pytanie w przeszłości i teraz nie pamiętam własnego wyjaśnienia.

Kilka razy w roku ktoś mnie o to poprosi. Chciałbym wskazać im jakiś szanowany artykuł, który to wyjaśnia.

Chcę wziąć adres URL pod adresem https://www.example.com/ i przekierować ruch na https://www.example2.com/ .

Uważam, że powinno to być technicznie możliwe, ale jest niepożądane. Co jest nie tak z tą metodą? Czy przeglądarki otrzymają wyskakujące okienko zabezpieczeń, ponieważ przekierowuję je na inną stronę? Czy ktoś może podać link do jakiejś poważnej dokumentacji, która to wyjaśnia?

Możesz to zrobić, obie strony muszą mieć ważny certyfikat SSL. W ten sposób przeglądarki nie wyświetlają wyskakującego okienka bezpieczeństwa. Jeśli jednak obie witryny istnieją na tym samym serwerze, obie domeny muszą być hostowane z różnych adresów IP.

Serwer WWW patrzy na nagłówek „Host” w żądaniu HTTP, aby zobaczyć, którą stronę ma obsługiwać. Negocjacja SSL odbywa się przed wysłaniem żądania HTTP, więc w tym momencie serwer internetowy nie może powiedzieć, którą stronę internetową wyświetli. Zawsze wysyła ten sam certyfikat do przeglądarki.

Można to obejść na dwa sposoby:

• Posiadaj certyfikat wieloznaczny dla * .example.com, aby wszystkie subdomeny mogły współdzielić ten sam certyfikat.
• Uruchom każdą witrynę SSL pod innym adresem IP. W ten sposób serwer internetowy wie, który certyfikat SSL może wysłać do przeglądarki, sprawdzając adres IP, który odebrał połączenie przychodzące.

Należy pamiętać, że można podłączyć wiele adresów IP do tej samej karty sieciowej, wystarczy, że potrzebujesz drugiego adresu IP dostępnego w przestrzeni adresów IP.

Aktualizacja: obecnie możesz obsługiwać wiele witryn SSL pod jednym adresem IP. Aby to włączyć, skonfiguruj obsługę SNI na swoim serwerze internetowym. Obsługuje to większość współczesnych przeglądarek (z wyjątkiem Windows XP i Androida 2).

Nigdy tego nie próbowałem, więc nie mówię z konkretnych doświadczeń, ale powinno działać. Musisz mieć ważny certyfikat SSL dla https://www.example.com, ponieważ nazwa hosta jest zaszyfrowana w nagłówku HTTP, więc Twój serwer nie będzie wiedział, aby przekierować, dopóki nie zostanie odszyfrowany. Następnie powinien przekierować jak normalne żądanie HTTP.

Dlaczego miałoby to być niepożądane?

Na przykład, Big Bank i Little Bank prowadzą witryny na https, aby zapewnić klientom poczucie bezpieczeństwa. Big Bank kupuje Little Bank. W pewnym momencie informatycy skonfigurują przekierowanie dla https://www.littlebank.com na https://www.bigbank.com . Jest to uzasadniony powód do przekierowania z https na https.

To powinno działać dobrze.

Jedynym rozłączeniem, które moim zdaniem jest obecne w obecnych odpowiedziach, które mogą się pojawić dla ciebie, jest to, że w każdej z tych okoliczności prawdziwe przekierowanie (tj. Przeglądarka zostanie ponownie przekierowana na www.example2.com) będzie w porządku, ale jeśli to zamaskujesz tak, że przeglądarka nadal uważa, że ​​jest skierowana na www.example.com, podczas gdy w rzeczywistości wysłałeś ją na www.example2.com, w tym miejscu zobaczysz ostrzeżenia bezpieczeństwa właśnie dlatego, że możesz próbować sfałszować użytkownika.

Krótka wersja to normalne przekierowanie powinno być w porządku, maskowanie adresów prawdopodobnie pozostawi wiele wyjaśnień.

Widząc to, problem ten można rozwiązać na warstwie transportowej. Załóżmy, że masz rekord DNS A, na przykład.com, wskazujący 192.168.0.1. Po wpisaniu https://example.com w przeglądarce komputer ustanawia połączenie TCP z serwerem o adresie IP 192.168.0.1, gdzie jakiś proces nasłuchuje na porcie 443. Co, jeśli w tym samym czasie serwer (który nie próbuje zapoznaj się ze szczegółami danych wysyłanych przez tę sesję TCP, takich jak rozpoczęcie negocjacji SSL), ustanawia połączenie TCP z 192.168.0.2 (inny serwer z DNS, na który wskazuje przykład2.com. Narzędzie linux HA zainstalowane na pierwszym serwerze może rozwiązać ten problem za pomocą taka konfiguracja:

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

Spowoduje to jednak błąd certyfikatu SSL, chyba że twój serwer www example2.com pokaże certyfikat SSL na przykład z CN = example2.com i SAN = example.com.

Lub możesz ustawić horyzont DNS DNS, gdy od użytkowników perstective example.com i example2.com rozstrzygną się na 192.168.0.1.