Перенаправити https на інший https

Я гугла за цим питанням і, як не дивно, не можу знайти конкретної відповіді. Я раніше відповідав на це питання, і тепер не можу пригадати власне пояснення.

Кілька разів на рік хтось попросить мене це зробити. Я хотів би вказати на якусь поважну статтю, яка пояснює це.

Я хочу взяти URL за адресою https://www.example.com/ і перенаправити трафік на https://www.example2.com/ .

Я вважаю, що це має бути технічно можливо, але небажано. Що не так з цим методом? Чи отримають браузери спливаючі вікна безпеки, оскільки я переспрямовую їх на інший сайт? Чи може хтось надати посилання на якусь респектабельну документацію, яка пояснює це?

Ви можете це зробити, обидва сайти повинні мати дійсний сертифікат SSL. Таким чином браузери не надаватимуть спливаюче вікно безпеки. Якщо обидва сайти існують на одному сервері, обидва домену потрібно розмістити з різних IP-адрес.

Веб-сервер розглядає заголовок "Хост" у HTTP-запиті, щоб побачити, який сайт він повинен обслуговувати. Узгодження SSL відбувається до відправлення запиту HTTP, тому в цей момент веб-сервер не може сказати, на якому веб-сайті він відображатиметься. Він завжди надсилатиме той самий сертифікат у браузер.

Є два способи подолати це:

• Майте сертифікат підстановки для * .example.com, щоб усі субдомени могли мати один і той же сертифікат.
• Запустіть кожен SSL-сайт за різною IP-адресою. Таким чином, веб-сервер знає, який SSL-сертифікат він може надіслати в браузер, перевіривши IP-адресу, яка отримала вхідне з'єднання.

Зауважте, що цілком можливо приєднати декілька IP-адрес до одного мережного адаптера, просто потрібна друга IP-адреса, наявна у вашому просторі IP-адрес.

Оновлення. На сьогоднішній день ви можете запускати кілька сайтів SSL за один IP. Щоб увімкнути це, налаштуйте підтримку SNI на своєму веб-сервері. Більшість сучасних браузерів (крім Windows XP та Android 2) підтримують це.

Я ніколи цього не пробував, тому не кажу з конкретного досвіду, але це має працювати. Вам потрібно мати дійсний сертифікат SSL для https://www.example.com, оскільки ім'я хоста зашифровано всередині заголовка HTTP, щоб ваш сервер не знав перенаправляти, поки не буде розшифровано. Після цього він повинен перенаправити так, як це було б звичайним запитом HTTP.

Чому це було б небажано?

Наприклад, Big Bank та Little Bank обидва веб-сайти працюють на https, щоб забезпечити клієнтам задоволення. Big Bank купує Little Bank. В якийсь момент ІТ-люди встановлять переспрямування https://www.littlebank.com на https://www.bigbank.com . Це законна причина перенаправити з https на https.

Це має добре працювати.

Одне відключення, яке, на мою думку, є присутнім у поточних відповідях, які можуть з’явитися для вас, - це те, що в будь-якому з цих обставин справжнє переспрямування (тобто: браузер перейменоване на www.example2.com) буде добре, але якщо ви замаскуєте це таким чином, що браузер stillthinks він загострений на www.example.com , коли в дійсності ви відправили його в www.example2.com, це те , де ви будете бачити попередження безпеки саме тому , що ви могли б намагатися обдурити користувач.

Коротка версія звичайного переадресації має бути добре, маскування адреси, ймовірно, залишить вам багато пояснень.

Як бачите, цю проблему можна вирішити на транспортному шарі. Скажімо, у вас є DNS Запис для example.com, що вказує на 192.168.0.1. Коли ви вводите https://example.com у веб-переглядачі, ваш ПК встановив TCP-з'єднання з сервером з IP 192.168.0.1, де деякий процес прослуховується на порту 443. Що робити, якщо одночасно сервер (який не намагається отримати детальну інформацію про дані, що надсилаються протягом цього сеансу TCP, як-от запуск узгодження SSL) встановлює TCP-з'єднання до 192.168.0.2 (на нього вказує ще один сервер з DNS. Примітка. такий конфігурація:

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

Але це призведе до помилки сертифіката SSL, якщо на веб-сервері example2.com не відображатиметься, наприклад, сертифікат SSL з CN = example2.com і SAN = example.com.

Або ви можете встановити горизонтальний протокол DNS, коли користувачі perstective example.com і example2.com вирішують на 192.168.0.1.