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

https://docs.google.com/document/d/1oRXJUIttqQxuxmjj2tgYjj096IKw4Zcw6eAoIKWZ2oQ/preview?sle=true
  • Перевод
В переводе этого документа описываются шаги, которые необходимо предпринять для перевода вашего сайта с HTTP на HTTPS. Шаги можно выполнять с любой скоростью – либо всё за день, либо один шаг за месяц. Главное, делать это последовательно.

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

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


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

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


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

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

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


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

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

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

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

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

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

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

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

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


Теперь, когда ваш сайт работает и на HTTP и на HTTPS, вам нужно добиться его работы вне зависимости от протокола. Может возникнуть проблема смешанных протоколов – когда на странице, которую грузят через 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="1450829848287066165294"/>
<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="1450829848287066165294"/>
<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.

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

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

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

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


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

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


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

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

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


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

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

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

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

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

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


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

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

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

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

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

Заголовки Referer

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

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

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

Согласно HTTP RFC:

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

Монетизация

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

Рекламодатели должны хотя бы предлагать вариант своих сервисов с поддержкой HTTPS (достаточно дойти до 2 шага этой инструкции). Многие так и делают. Вам, возможно, придётся отложить 4-й шаг до тех пор, пока большинство из них не станут нормально поддерживать этот протокол.
Метки:
Поделиться публикацией
Комментарии 16
  • +4
    И только вчера я на startssl перенагенерил себе сертификатов для почты и нескольких доменов :-)
    Тоже думал написать такое, но потом решил что слишком банально…
  • +5
    Добейтесь того, чтобы сайт заслуживал оценки A или A+.
    О да. Прямо как в картинке про нарисуйте сову.
    Стоит так же указать, что добиться этого один раз недостаточно. С момента миграции нужно постоянно следить за новостями в мире ssl и время от времени тюнить конфиг, иначе скатитесь в F с конфигурацией, которая прежде была отличной.
    • 0
      в инструкции по переходу на https не хватает «настройте вот этот бесплатный сервис который пришлет вам email если оценка снизится»
      • 0
        А такой есть? С появлением API на ssllabs чесались руки написать что-то наколеночное в крон, но потом как-то передумалось.
        • 0
          Мне о таком неизвестно. Я лишь говорю о том, что в инструкции по переходу на https ссылки на такой скрипт / сервис не хватает. :)
        • 0
          page2rss + ifttt?
  • 0
    Еще можно включить поддержку SPDY протокола, тем более тот же NGINX поддерживает его «из коробки» для версий 1.6.1+.

    Секцию SERVER конфига, где указываем какие порты слушать, приводим к такому виду:

     listen 443 ssl spdy;
     listen [::]:443 ssl spdy;
    


    Сохраняем, перезагружаем NGINX. Скорость отдачи контента станет еще чуть выше.
  • +3
    Сегодня прям день https =) В соседней теме я дал ссылку на свои настройки, А+ есть.
    • 0
      Кстате спасибо, поднял свой с C до A :-)
  • +1
    Автор приводит ссылку на хелп гугла, где написано: «it's common for the same content to be accessed through multiple URLs.» Т.е. этот метатег устанавливать нужно когда один и тот же контент доступен по разным урлам, например разным гет параметрам и нужно сообщить роботу канонический урл — то есть общий урл для всей группы урлов. В случае с https уже сделана переадресация, больше ничего не нужно. Собственно, это подтвердила служба поддержки Яндекса недавно, когда обращался по этому вопросу.
    • 0
      Также добавлю, что переход на https обрушил трафик с яндекса в 5 раз. В службе поддержки сказали, что нужно ждать несколько недель пока все устаканится.
  • 0
    «На этой странице есть инструкция для этого» — на какой?
  • +1
    pastebin.com/6X8yEbCN можно этот конфиг взять за основу, даёт A+ на ssllabs и поддерживает Internet Explorer 8 на Windows XP. server.com заменить на ваш сайт, в файл /etc/nginx/ssl/server.com-chain.crt положить сертификаты начиная от вашего (включая) до корневого (исключая), в файл /etc/nginx/ssl/server.com-stapling.crt положить сертификаты от корневого (включая) до вашего (исключая) (порядок вроде не влияет). Public-Key-Pins тут должны быть ваши публичные RSA ключи, инструкцию по получению нагуглить несложно (один ключ, использующийся для HTTPS, второй ключ запасной, если первый потеряете).
  • –3
    > 3: Сделайте все внутренние ссылки относительными

    Чушь. Не «ссылки сделайте относительными», а «уберите из внутренних ссылок указание на протокол там, где оно есть» (этот вариант, кстати, указывается в статье — вместо httр://domain.com использовать //domain.com). Менять httр://domain.com/css/main.css на относительный путь (т.е. ../css/main.css) никак не поможет в переходе на https.

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

    Вкратце и без многих слов — сделайте с http-версии 302 редиректы на https адреса тех же страниц, и будет вам счастье. Заодно не забудьте в robots.txt указать канонический хост с указанием протокола: вместо

    Host: domain.com

    напишите

    Host: httрs://domain.com

    и в sitemap.xml не забудьте то же сделать.
  • 0
    По мне так шаг 3 должен быть первым.

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