Редиректы с использованием HTTPS

В связи с массовым переходом веб-сайтов на HTTPS перед разработчиками и администраторами веб-сайтов встал ряд новых проблем. Одной из них будет редирект с HTTP на HTTPS и необходимость правильно обрабатывать переадресацию на канонический адрес веб-сайта, чтобы избежать дублирования контента.

HTTPS и редиректы

Рассмотрим пример. Допустим, что у нас есть веб-сайт dnsimple.com. Его канонический URL-адрес — https://dnsimple.com. Тем не менее, существует четыре разных метода, при помощи которых можно без проблем подключиться к веб-сайту, и необходимо обеспечить, чтобы при любом из них посетитель перенаправлялся на https://dnsimple.com:

Исходный метод Тип
http://dnsimple.com HTTP + no-www
https://dnsimple.com HTTPS + no-www
http://www.dnsimple.com HTTP + www
https://www.dnsimple.com HTTPS + www

Параметр htaccess редиректов HTTP на HTTPS часто будет причиной путаницы. Не понятно, как правильно обрабатывать через HTTPS редиректы с WWW на не-WWW(или наоборот), и почему для этого нужен сертификат SSL / TLS. Чтобы правильно изменить данные перенаправления, надо понять основные принципы обработки запросов HTTPS.

Далее мы рассмотрим, в каком порядке устанавливается соединение по протоколу HTTPS, как происходит обработка HTTP-запросов и параметр редиректов с поддержкой HTTPS.

Поток запроса HTTPS

Редиректы с использованием HTTPS На приведенном выше изображении показана схема прохождения запросов / ответов HTTPS. Для простоты мы разбили все действия на три фазы:

  1. На первом этапе покупатель и сервер договариваются о деталях шифрования, таких как протокол шифрования и набор шифров. Также происходит обмен информацией, необходимой для переключения на защищенное соединение: открытые ключи, сведения о сертификате и т.д. Эта фаза называется «SSL / TLS рукопожатие»;
  2. На втором этапе покупатель готовит HTTP-запрос, шифрует его и отправляет на сервер для обработки. Сервер принимает зашифрованный HTTP-запрос, расшифровывает его, обрабатывает и выдает HTTP response(ответ);
  3. На третьем этапе, сервер шифрует ответ и отправляет его покупателю для обработки. Покупатель получает зашифрованный HTTP response, дешифрует и обрабатывает его(например, браузер начинает загружать и выводить элементы).

Эта схема потока редиректа с HTTP на HTTPS применима к любому запросу, независимо от содержимого ответа HTTP.

Выше я написал запрос HTTP и ответ HTTP для определенных целей(обратите внимание, что я использовал HTTP, а не HTTPS). С точки зрения содержимого и структуры важно понимать, что HTTPS-запрос — это HTTP-запрос, но передаваемый через защищенное соединение(TLS / SSL).

HTTPS-согласования и редиректы

Одна из самых распространенных ошибок при параметру HTTPS-редиректов — это предположение, что вам не нужен сертификат SSL при переадресации покупателя с одного домена на другой.

Если посмотреть на поток запросов, то видно, что обмен сертификатами SSL и согласование шифрования выполняются на первом этапе. Обратите внимание, что на этом этапе сервер ничего не знает, какая страница нужна покупателю: покупатель и сервер решают, как взаимодействовать друг с ином.

После завершения первого этапа, когда покупатель и сервер нашли общий язык(протокол шифрования), они могут начать взаимодействовать друг с ином, используя зашифрованное соединение. В этот момент покупатель отправляет HTTP-запрос на сервер, а сервер отправляет HTTP-ответ, содержащий редирект.

Не забывайте, что редирект — это HTTP-ответ с кодом 301(иногда 302 или 307):

HTTP/1.1 301 Moved PermanentlyServer: nginxDate: Mon, 01 Aug 2016 14:41:25 GMTLocation: https://dnsimple.com/

Перед тем, как сделать редирект с HTTPS на HTTP, помните, что, если необходимо создать редирект для всего домена, то необходим валидный сертификат SSL для перенаправляемого домена. Для согласования шифрования требуется сертификат SSL, и происходит оно до того, как запрос был обработан, а ответ о редиректе возвращен покупателю.

Если бы все происходило иначе, то редирект бы обрабатывался перед проверкой сертификата SSL. Тогда покупатель и сервер были бы вынуждены общаться при помощи обычного HTTP-соединения, которое не шифруется.

Если необходимо перенаправить покупателя с любой страницы домена https://www.example.com на другую, необходим установленный на сервере валидный сертификат SSL, который распространяется на весь домен www.example.com.

К примеру, чтобы перенаправить покупателя с https://www.example.com на https://example.com, надо иметь сертификат, который распространяется на оба или два отдельных сертификата (для каждого хоста соответственно).

Стратегии HTTPS-редиректов

Мы рассмотрели, как обрабатывается редирект с HTTP на HTTPS через htaccess после SSL / TLS согласования. А также выяснили, что для перенаправления покупателей с веб-сайта или страницы на HTTPS нужен валидный сертификат SSL , который охватывает оба домена. Далее я расскажу об общих стратегиях параметра HTTPS-редиректов .

Существует два типа параметра редиректов с HTTPS :

  1. Редирект на уровне сервера;
  2. Редирект на уровне приложений.

Термин сервер обозначает любой сервер, который находится перед веб-приложением и обрабатывает входящий HTTP-запрос . Например, front-end сервер, сервер балансировки нагрузки или единичного приложения.

Термин приложение обозначает веб-приложение, которое может быть либо столь же простым, как PHP-скрипт , либо более сложным, таким как серверное Unicorn-приложение интерпретации Ruby on Rails .

Выполнение HTTPS-редиректов на уровне сервера

Выполнение HTTPS-редиректов на уровне сервера будет более предпочтительным. В этом случае сервер, на котором установлен сертификат SSL , принимает зашифрованный HTTP-запрос и возвращает зашифрованный HTTP-ответ о редиректе в соответствии с настройками конфигурации без соединения с сервером приложения или выполнения кода приложения.

Редиректы с использованием HTTPS Такой подход будет более быстрым, поскольку сервер может обрабатывать редирект без взаимодействия с приложением. В то же время конфигурация серверов менее гибкая по сравнению с тем, что можно сделать при помощи полноценного языка программирования. htaccess редирект HTTP на HTTPS на уровне сервера используется для массового перенаправления. К примеру, редиректа с WWW на не-WWW версию домена с HTTPS (или наоборот).

Следующий фрагмент кода будет примером конфигурации Nginx , в котором задается редирект с http://example.com , http://www.example.com и https://www.example.com на https://example.com :

server { listen 80; server_name example.com www.example.com; return 301 https://example.com$request_uri;}server { listen 443 ssl; server_name example.com www.example.com; # ssl configuration ssl on; ssl_certificate /path/to/certificate.crt; ssl_certificate_key /path/to/private.key; if ($http_host = www.example.com) { return 301 https://example.com$request_uri; }}

Реализация редиректа на уровне сервера более предпочтительна, но она не осуществима, так как вы можете не иметь доступа к конфигурации сервера. Это касается виртуального веб-хостинга или таких платформ, как Heroku , Azure или Google Platform .

Выполнение HTTPS-редиректа на уровне приложений

Когда у вас нет доступа к конфигурации сервера, или логика редиректа будет более сложной, надо обрабатывать редирект с HTTP на HTTPS на уровне приложений.

Редиректы с использованием HTTPS Такой подход медленнее, так как сервер должен принять запрос, обработать программный код приложения (или взаимодействовать с сервером приложений) и вернуть ответ.

То, как выполняется редирект на уровне приложений, зависит от используемого языка программирования и стека. Вот пару примеров.

Пакет Goland и net/http

Можно использовать http.Redirect .

Ruby on Rails

Можно изменить редирект на уровне маршрутизатора, использовать промежуточное программное обеспечение Rack или способ redirect_to внутри контроллера:

constraints(host: /www.example.com/) do get '*', to: redirect('https://example.com')end

PHP

Используйте возможность header , чтобы отправить HTTP-заголовок перенаправления:

<?phpheader('Location: https://example.com/');exit;?>

В некоторых случаях это единственно возможный подход. Например, если необходимо перенаправить покупателей с WWW на не-WWW версию домена, с HTTPS на Heroku или Azure (или наоборот), то придется указать оба домена в одном приложении, установить сертификат и через условия обрабатывать редирект на уровне приложений.

Альтернативные методы выполнения HTTPS-редиректа

Существует пару альтернативных методов редиректа с HTTP на HTTPS .

В некоторых ситуациях отсутствует доступ к конфигурации сервера, а платформа, на которой размещен веб-сайт, не может использовать язык программирования. В виде типичного примера можно привести Amazon S3 для размещения статических веб-сайтов. В этом случае необходимо выяснить, предлагает ли платформа настройки HTTPS-редиректов , которые можно без проблем изменить.

Другой вариант заключается в использовании автономного, независимого приложения для редиректов. Например, если необходимо перенаправить покупателей с https://alpha.com на https://beta.com . Тогда для домена alpha.com в виде DNS можно указать другой сервис или сервер, на котором размещен beta.com . А также изменить редирект на уровне сервера или установить приложение, которое будет выступать в виде редиректора. При этом также необходим валидный сертификат для alpha.com , который будет установлен там, где надо осуществить редирект.

Заключение

Учитывая, что HTTPS становится стандартом для веб-сайтов, важно надлежащим образом изменить соответствующие редиректы для предотвращения появления дублированного содержимого и перевода веб-сайта на использование HTTPS-версии .

Для создания HTTPS-редиректов требуются дополнительные действия, чтобы перенаправляемый сервер был в состоянии обработать входящие HTTPS-запросы и отправить правильный ответ о редиректе.

Существует много методов обработки URL-редиректов , и, надеюсь, эта статья помогла вам найти подходящий вариант, как сделать редирект с HTTPS на HTTP .

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *