Назад | Перейти на главную страницу

Перенаправить https на другой https

Я искал этот вопрос в Google, и по иронии судьбы досадно, что я не могу найти конкретного ответа. Я сам отвечал на этот вопрос в прошлом, и теперь я не могу вспомнить собственное объяснение.

Несколько раз в год меня будут просить об этом. Я хотел бы указать им на какую-то респектабельную статью, которая это объясняет.

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

Я считаю, что это должно быть технически возможно, но нежелательно. Что не так с этим методом? Будут ли браузеры получать всплывающее окно безопасности, если я перенаправляю их на другой сайт? Может ли кто-нибудь дать ссылку на какую-нибудь приличную документацию, которая объясняет это?

Вы можете сделать это, у обоих сайтов должен быть действующий сертификат SSL. Таким образом, браузеры не будут отображать всплывающее окно безопасности. Однако, если оба сайта существуют на одном сервере, оба домена должны размещаться с разных IP-адресов.

Веб-сервер просматривает заголовок «Host» в 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, чтобы дать клиентам чувство безопасности. Большой банк покупает Маленький банк. В какой-то момент ИТ-специалисты настроят перенаправление для https://www.littlebank.com к https://www.bigbank.com. Это законная причина для перенаправления с https на https.

Это должно работать нормально.

Единственное несоответствие, которое, как мне кажется, присутствует в текущих ответах, которые могут возникнуть у вас, заключается в том, что в любом из этих обстоятельств истинное перенаправление (то есть: браузер перенаправляется на www.example2.com) будет прекрасным, но если вы замаскируете это так что браузер все еще думает, что он указывает на www.example.com, хотя на самом деле вы отправили его на www.example2.com, этот здесь вы увидите предупреждения системы безопасности именно потому, что вы можете попытаться обмануть пользователя.

Краткая версия - обычное перенаправление, должно быть нормально, маскировка адреса, вероятно, заставит вас много объяснять.

Как видим, эту проблему можно решить на транспортном уровне. Допустим, у вас есть запись DNS A для example.com, указывающая на 192.168.0.1. Когда вы печатаете https://example.com в браузере ваш компьютер установил TCP-соединение с сервером с IP 192.168.0.1, где какой-то процесс прослушивает порт 443. Что, если в то же время сервер (который не пытается получить подробную информацию о данных, отправленных по этому TCP сеанс, такой как начало согласования SSL) устанавливает TCP-соединение с 192.168.0.2 (другой сервер с DNS A example2.com, указывающим на него. Установленная на первом сервере утилита HA proxy linux может решить эту проблему с такой конфигурацией:

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 slpit horizon, когда пользователи perstective example.com и example2.com разрешают 192.168.0.1.