Мигрируем на HTTPS

В переводе этого документа описываются шаги, которые необходимо предпринять для перевода вашего сайта с HTTP на HTTPS. Шаги можно выполнять с любой скоростью – либо всё за день, либо один шаг за месяц. Главное, делать это последовательно.

Каждый шаг улучшает ваш сервер и важен сам по себе. Однако, сделать их все – обязательно для того, чтобы гарантировать безопасность вашим посетителям.

Для кого предназначена эта инструкция?

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

1: Получение и установка сертификатов

Если вы ещё не получили сертификаты – необходимо выбрать поставщика, и купить сертификат. Сейчас есть пара возможностей даже получить сертификаты бесплатно – например, их выдаёт контора RapidSSL. Кроме того, в 2015 году Mozilla обещают сделать бесплатную выдачу сертификатов ^[1].

Скопируйте полученные сертификаты на ваши фронтенд-сервера куда-нибудь в /etc/ssl (Linux / Unix) или в приемлемое место для IIS (Windows).

2: Включение HTTPS на сервере

Здесь надо определиться:

— либо использовать хостинг ^[2] по IP, когда у каждого хоста свой IP
— либо отказаться от поддержки пользователей, которые сидят используют IE на Windows XP или Android с версией менее 2.3

На большинстве сайтов настроен виртуальный хостинг ^[2], который работает с доменными именами (name-based) – это экономит IP-адреса и вообще более удобно. Проблема в том, что IE и древний Android не понимают Server Name Indication ^[3](SNI), а это критично для работы HTTPS при name-based хостинге ^[2].

Когда-нибудь все эти клиенты вымрут. Вы можете отслеживать количество таких клиентов и решить, нужно их поддерживать или нет.

Далее настройте поддержку сертификатов, которые вы получили, в вашем веб-сервере. Конфигурацию сервера можно создать через Mozilla configuration generator ^[4]или SSLMate ^[5].

Если у вас много хостов и поддоменов – кажды из них потребует установки подходящего сертификата. Для поддоменов лучше использовать сертификаты с маской типа *.domain.ru

В идеале, вам необходимо переадресовывать все запросы к HTTP на HTTPS и использовать Strict Transport Security (см. шаги 4 и 5)

После этого проверьте работу сайта с новыми настройками при помощи инструмента Qualys SSL Server Test ^[6]. Добейтесь того, чтобы сайт заслуживал оценки A или A+.

3: Сделайте все внутренние ссылки относительными

Теперь, когда ваш сайт работает и на HTTP и на HTTPS, вам нужно добиться его работы вне зависимости от протокола. Может возникнуть проблема смешанных протоколов ^[7]– когда на странице, которую грузят через HTTPS, указаны ресурсы, доступные по HTTP. В этом случае браузер предупредит пользователя, что защита, предоставляемая HTTPS, перестала работать на 100%.

По умолчанию многие браузеры вообще не будут загружать смешанный контент. Если это будут скрипты или стили, страница перестанет работать. К слову, включать в страницу, загруженную по HTTP, контент, доступный через HTTPS, можно без проблем.

Проблема эта решается заменой полных линков на относительные. Вместо такого:

<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>
<p>Read this nice <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="http://foo.com/">other cool site.</a></p>

надо сделать такое:

<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>
<p>Read this nice <a href="//example.com/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="http://foo.com/">other cool site.</a></p>

или такое:

<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>
<p>Read this nice <a href="/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="http://foo.com/">other cool site.</a></p>

Все линки должны быть относительными, и чем относительнее, тем лучше. По возможности надо убрать протокол (//example.com) или домен (/jquery.js).

Лучше делать это при помощи скриптов, и не забыть про контент, который может находиться в базах данных, скриптах, стилях, правилах редиректа, тегах link. Проверить сайт на наличие смешанного контента можно скриптом от Bram van Damme ^[8].

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

Если в вашем сайте используются скрипты и другие ресурсы от третьих лиц, например CDN, jquery.com, у вас есть 2 варианта:

— также использовать URL без указания протокола
— скопируйте эти ресурсы к себе на сервер. Это в любом случае надёжнее

4: Переадресация с HTTP на HTTPS

Установите тег

<link rel="canonical" href="https://…"/> 

на ваших страницах. Это поможет поисковым системам ^[9]лучше ориентироваться у вас.

Большинство веб-серверов предлагают простые решения для редиректа. Инструкции для Apache ^[10]и для nginx ^[11]. Используйте код 301 (Moved Permanently).

5: Включите Strict Transport Security и Secure Cookies

На этом шаге вы уже ограничиваете доступ к сайту только для HTTPS. Strict Transport Security ^[12]сообщает клиентам, что им надо соединяться с сайтом только по HTTPS, даже если ссылка идёт на . Это помогает против атак типа SSL Stripping ^[13]и экономит время на переадресациях из четвёртого шага.

Убедитесь, что ваши TLS-настройки реально работают – например, сертификат не просрочен. На этом шаге любая ошибка будет блокировать доступ к сайту.

Включите HTTP Strict Transport Security посредством заголовка Strict-Transport-Security. На этой странице ^[14]есть ссылки на инструкции для разных серверов.

Примечание: max-age измеряется в секундах. Начните с небольших величин и по мере роста уверенности в работе сайта увеличивайте их.

Для того, чтобы клиенты всегда отправляли куки по защищённому каналу, включите флаг Secure для куков. На этой странице есть инструкция для этого.

Проблемы с миграцией

Позиция в поисковой выдаче

Google ставит наличие HTTPS в плюс сайтам ^[15]. У Google также есть инструкция ^[16]по тому как переходить на безопасный режим, не теряя позиций в поиске. Также такие инструкции ^[17]есть у Bing.

Быстродействие

Когда сервер работает нормально, траты на TLS обычно малы. По поводу их оптимизации читайте High Performance Browser Networking by Ilya Grigorik ^[18] и Ivan Ristic’s OpenSSL Cookbook ^[19] и Bulletproof SSL And TLS ^[20].

В некоторых случаях TLS может увеличить быстродействие – это справедливо в случае использования HTTP/2.

Заголовки Referer

Клиентские программы не отправляют Referer, когда пользователи переходят по ссылкам с вашего HTTPS-сайта на другие HTTP-сайты. Если вам это не нравится:

— другие сайты тоже должны мигрировать на HTTPS. Предложите им эту инструкцию. Если они дойдут хотя бы до 2 шага, то ситуация выправится
— вы можете использовать новый стандарт Referrer Policy ^[21], решающий проблемы с этими заголовками

Так как поисковики мигрируют на HTTPS, то вы скорее всего получите больше заголовков Referer, когда сами перейдёте на HTTPS.

Согласно HTTP RFC ^[22]:

Клиент НЕ ДОЛЖЕН включать заголовок Referer в небезопасный HTTP-запрос, если ссылающаяся страница получена по безопасному протоколу.

Монетизация

Если на вашем сайте крутятся объявления рекламной сети, может возникнуть проблема –iframe с HTTP не будут работать на странице с HTTPS. Пока все рекламодатели не перейдут на HTTPS, операторы не могут перейти на HTTPS, не теряя рекламных доходов. Но пока операторы не мигрируют на HTTPS, у рекламодателей нет мотивации для миграции.

Рекламодатели должны хотя бы предлагать вариант своих сервисов с поддержкой HTTPS (достаточно дойти до 2 шага этой инструкции). Многие так и делают. Вам, возможно, придётся отложить 4-й шаг до тех пор, пока большинство из них не станут нормально поддерживать этот протокол.

Автор: SLY_G

Источник ^[23]