Missed the action at this year's Chrome Dev Summit? Catch up with our playlist on YouTube. Watch now.

Enabling HTTPS on Your Servers

TL;DR

  • Create a 2048-bit RSA public/private key pair.
  • Generate a certificate signing request (CSR) that embeds your public key.
  • Share your CSR with your Certificate Authority (CA) to receive a final certificate or a certificate chain.
  • Install your final certificate in a non-web-accessible place such as /etc/ssl (Linux and Unix) or wherever IIS requires it (Windows).

Generating keys and certificate signing requests

В данном разделе для генерации открытых/закрытых ключей и запросов на получение сертификата CSR используется консольная программа openssl, стандартная для большинства операционных систем Linux, BSD и Mac OS X.

TL;DR

  • Для этого вам понадобится создать пару из открытого и закрытого 2048-разрядных ключей с использованием криптосистемы RSA.
  • Сформируйте запрос на получение сертификата (CSR), в который встраивается ваш открытый ключ.
  • Передайте ваш CSR в сертифицирующий орган для получения окончательного сертификата или цепочки сертификатов.
  • Поместите окончательный сертификат в хранилище, куда невозможно попасть через Интернет, например в /etc/ssl (для Linux и Unix) или в другое место, рекомендуемое IIS (для Windows).

Создание пары открытого/закрытого ключей

В данном примере мы создадим пару 2048-разрядных ключей с использованием криптосистемы RSA. (Более короткие ключи, например 1024-разрядные ключи, могут быть подобраны с использованием метода полного перебора возможных комбинаций. Более длинные ключи , например 4096-разрядные, использовать нецелесообразно. С течением времени длина ключей растет, поскольку вычислительные мощности дешевеют. Идеальным вариантом на сегодняшний день являются 2048-разрядные ключи.

Ниже приведена команда для генерации пары ключей с использованием криптосистемы RSA:

openssl genrsa -out www.example.com.key 2048

Она возвращает следующее:

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

Генерация запроса на получение сертификата CSR

На этом этапе вы размещаете свой открытый ключ и информацию о своей организации и вашем веб-сайте в запросе на получение сертификата, и эти данные запросит у вас openssl.

Выполнение этой команды:

openssl req -new -sha256 -key www.example.com.key -out

www.example.com.csr

Вернет следующее:

You are about to be asked to enter information that will be incorporated
into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) []:Mountain View
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (eg, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Теперь необходимо убедиться в корректности CSR; это можно сделать с помощью следующей команды:

openssl req -text -in www.example.com.csr -noout

Ответ программы должен выглядеть следующим образом:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
                    f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
                    ...
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
         2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
         ...

Предоставление CSR сертифицирующему органу

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

Отправьте сертифицирующему органу свой CSR и следуйте предоставляемым инструкциям для получения окончательного сертификата или цепочки сертификатов.

Различные сертифицирующие органы взимают различную плату за услуги сертификации вашего открытого ключа.

Также существует возможность назначить ваш ключ нескольким доменным именам, включая несколько конкретных имен (например, example.com, www.example.com, example.net, и www.example.net), а также группе имен с подстановочными символами, например, *.example.com.

Например, один из сертифицирующих органов предлагает следующие расценки:

  • Стандартный пакет: $16/год для доменных имен example.com и www.example.com.
  • Групповой пакет: $150/год для доменных имен example.com и *.example.com.

По этим расценкам получение сертификатов для группы доменных имен становится выгодным, если у вас в наличии более 9 дочерних доменов; в остальных случаях вы можете приобрести сертификаты на каждое имя по отдельности. Если , например, у вас более 5 дочерних доменов, получение сертификатов для группы имен может оказаться для вас более удобным, если вам понадобится использовать протокол HTTPS на своих серверах).

ПРИМЕЧАНИЕ. Помните, что групповой пакет сертификатов предполагает подстановку символов только в первой части доменного имени. Сертификат для *.example.com подойдет для foo.example.com и bar.example.com, но не для foo.bar.example.com.

Поместите сертификат в хранилища на внешних серверах, куда невозможно попасть через Интернет , например в /etc/ssl (для Linux и Unix), или в другое место, рекомендуемое IIS (для Windows).

Enable HTTPS on your servers

На этом этапе необходимо принять важнейшее эксплуатационное решение:

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

Если для каждого имени хоста используется отдельный IP-адрес, это замечательно! Вы можете с легкостью поддерживать HTTP и HTTPS для всех клиентов.

Однако операторы большинства сайтов используют виртуальный хостинг на базе имен — это позволяет сохранить IP-адреса и в общем и целом более удобно. Проблема с IE в Windows XP и Android версии ранее 2.3 состоит в том, что они не понимают обозначение имени сервера Server Name Indication (SNI), которое является ключевым для виртуального хостинга на базе имен для HTTPS.

Когда-нибудь, будем надеяться, что скоро, на смену клиентам, которые не поддерживают SNI, придет более современное программное обеспечение. Контролируйте строку агента пользователя в журналах запросов, чтобы узнать, когда достаточное количество ваших пользователей перейдет на современное программное обеспечение. (Вы можете решить, что ваш порог составляет, скажем < 5 % или < 1 % и т. п.)

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

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

Теперь, пока существует ваш сайт, проверяйте конфигурацию HTTPS с помощью удобного теста SSL Server Test Qualys. Ваш сайт должен получать оценку A или A+. Любые причины более низкой оценки должны расцениваться как ошибка. (Сегодняшний уровень A завтра превратится в B, поскольку атаки на алгоритмы и протоколы становятся все более изощренными!)

Make intrasite URLs relative

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

На самом деле в случае активного смешанного контента (скрипты, плагины, таблицы стилей CSS, плавающие фреймы iframe), браузеры зачастую просто не загружают и не исполняют контент — в результате мы получаем нерабочую страницу.

ПРИМЕЧАНИЕ. Все работает, когда на HTTP-странице включены HTTPS-ресурсы.

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

Такие проблемы возникают, когда на вашей странице есть полноценные внутренние ссылки, использующие схему http://. Вам следует изменить контент следующим образом:

    <h1>Добро пожаловать на 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>Читайте нашу новую<a href="http://example.com/2014/12/24/">интересную
    публикацию о кошках!</a></p>
    <p>Загляните на этот <a href="http://foo.com/">прикольный
    сайт.</a></p>

замените на:

    <h1>Добро пожаловать на 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>Читайте нашу новую<a href="//example.com/2014/12/24/">интересную
    публикацию о кошках!</a></p>
    <p>Загляните на этот <a href="http://foo.com/">прикольный
    сайт.</a></p>

или:

    <h1>Добро пожаловать на 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>Читайте нашу новую <a href="/2014/12/24/">интересную
    публикацию о кошках!</a></p>
    <p>Загляните на этот <a href="http://foo.com/">прикольный
    сайт.</a></p>

Таким образом внутренние ссылки становятся как можно более относительными: либо относятся к протоколу (не имеют протокола, начинаются с //example.com), либо к хосту (начинаются с пути, например, с /jquery.js).

ПРИМЕЧАНИЕ. Делайте это не вручную, а с помощью скрипта. Если содержимое вашего сайта находится в базе данных, протестируйте ваш скрипт на резервной версии базы данных, используемой для разработки. Если содержимое вашего сайта – простые файлы, протестируйте ваш скрипт на резервной копии файлов, используемой для разработки. Отправляйте изменения в производство только после того, как они прошли проверку на качество. Можете использовать скрипт [Bram van Damme's] (https://github.com/bramus/mixed-content-scan) или аналогичные решения, чтобы определить смешанный контент на вашем сайте.

ПРИМЕЧАНИЕ. При указании ссылок на другие сайты (вместо того чтобы включать фрагменты их ресурсов) не изменяйте протокол, поскольку вы не контролируете работу этих сайтов.

ПРИМЕЧАНИЕ. Я рекомендую ссылки, зависящие от протокола, с тем чтобы миграция больших сайтов проходила более гладко. Если вы не уверены, что сможете полностью перейти на HTTPS, принудительное использование HTTPS для всех ресурсов вашего сайта может стать рискованным. Скорее всего, поначалу HTTPS будет казаться вам новым и непонятным, и в этот период HTTP-версия должна продолжать нормально работать. Спустя некоторое время вы завершите миграцию и можете работать только в HTTPS (см. следующие два раздела).

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

Использовать для этих ресурсов ссылки, также зависящие от протокола. Если третья сторона не работает с HTTPS, попросите их об этом. В большинстве своем такие третьи лица уже поддерживают этот протокол, например jquery.com. Используйте ресурсы со своих серверов, работающих как с протоколом HTTP, так и с HTTPS. Это всегда целесообразно, поскольку дает вам возможность лучше контролировать внешний вид, производительность и безопасность вашего сайта – вам не нужно полагаться на третьих лиц, что всегда неплохо.

Помните, что вам также будет необходимо изменить URL-адреса внутри сайта в таблицах стилей, JavaScript, правилах перенаправления, <ссылочных...> тегах и синтаксических конструкциях на CSP-страницах, а не только на HTML-страницах!

Redirect HTTP to HTTPS

Вставьте на свои страницы теги <link rel="canonical" href="https://…"/>. Это позволит поисковым системам определить наилучший способ перейти на ваш сайт.

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

Turn on Strict Transport Security and secure cookies

На этом этапе мы уже "зафиксировали" использование протокола HTTPS. Сначала воспользуйтесь механизмом Strict Transport Security, чтобы указать клиентам, что для подключения к вашему серверу следует всегда использовать протокол HTTPS, даже при переходе по ссылке http://. Это позволит защититься от атак типа SSL Strip, а также избежать затрат, связанных с кодом перенаправления 301, о чем мы рассказали в разделе "Перенаправление с HTTP на HTTPS".

ПРИМЕЧАНИЕ. Существует высокая вероятность, что у клиентов, которые отметили ваш сайт как известный узел HSTS, возникнет серьезный сбой](https://tools.ietf.org/html/rfc6797#section-12.1), _если в конфигурации TLS вашего сайта имеется ошибка (например, просроченный сертификат). Такое поведение явным образом задано в самом механизме HSTS; это позволяет гарантировать, что злоумышленники не смогут обмануть клиентов, заставив их перейти на сайт по незащищенному протоколу. Не включайте HSTS, пока тщательно не проработаете ваш сайт, чтобы избежать развертывания HTTPS с ошибками проверки сертификата.

Чтобы включить механизм HSTS, задайте заголовок Strict-Transport-Security. На странице OWASP, посвященной HSTS, имеются ссылки на соответствующие инструкции для различного серверного ПО.

Большинство веб-серверов оснащены аналогичной функцией добавления настраиваемых заголовков.

ПРИМЕЧАНИЕ. Значение параметра "max-age" задается в секундах. Для начала можно указать небольшие значения, а затем постепенно увеличивать значение параметра "max-age" по мере более уверенного перехода на использование только HTTPS для своего сайта.

Также важно обеспечить, чтобы клиенты никогда не отправляли файлы cookie (например, для аутентификации или передачи настроек сайта) по протоколу HTTP. Например, если файл cookie пользователя с данными аутентификации представлен в виде обычного текста, безопасность всего сеанса подключения гарантированно будет нарушена, даже если все остальное было сделано правильно.

Поэтому ваше приложение должно всегда устанавливать флаг Secure для файлов cookie. На этой странице OWASP поясняется, каким образом флаг Secure устанавливается в ряде платформ приложений. В каждой платформе приложений имеется способ установить такой флаг.

Migration concerns

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

Производительность

Когда работа над слоями контента и приложений завершена (прекрасные рекомендации по этому вопросу изложены в руководствах Стива Саудерса), остается такая мелочь по сравнению с общими затратами на приложение , как настройка производительности TLS. Кроме того, у вас есть возможность сократить эти затраты и даже полностью избавиться от них. (Отличные советы по поводу оптимизации TLS и не только предлагаются в книге High Performance Browser Networking Ильи Григорика.) Также рекомендуем ознакомиться с книгами OpenSSL Cookbook и Bulletproof SSL And TLS Айвана Ристика.

В некоторых случаях повысить производительность TLS можно в основном за счет реализации возможностей HTTP/2. Об этом говорил Крис Палмер в своем выступлении, посвященном производительности HTTPS и HTTP/2, на саммите разработчиков Chrome 2014.

Заголовки источников ссылок

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

  • Другим сайтам следует перейти на HTTPS. В таком случае владельцам сайтов будет полезно ознакомиться с этим руководством! :) Если владелец сайта, на который имеется ссылка, выполнит инструкции из раздела данного руководства "Включение HTTPS на ваших серверах", вы можете изменить на своем сайте формат ссылок на другие сайты (поменять http:// на https://) или воспользоваться ссылками на основе протокола.
  • Можно воспользоваться новым стандартом политики в отношении источников ссылок , чтобы обойти различные проблемы, связанные с заголовками источников ссылок.

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

Клиентам НЕ СЛЕДУЕТ включать поле заголовка источника ссылки в запросы HTTP (по незащищенному протоколу), если для передачи страницы с исходной ссылкой использовался защищенный протокол.

В соответствии с требованиями стандарта RFC для HTTP

Доход от рекламы

Операторы сайтов, получающие доход от рекламы, размещенной на своих сайтах, хотят убедиться, что переход на HTTPS не скажется негативно на показах рекламы. Однако ввиду требований к безопасности смешанного контента элементы iframe HTTP блокируются на странице HTTPS. Это довольно щекотливый вопрос, требующий коллективных усилий: до тех пор, пока рекламодатели не начнут использовать протокол HTTPS, операторы сайтов не смогут перейти на HTTPS без потери доходов от рекламы; с другой стороны, до тех пор, пока операторы сайтов не перейдут на HTTPS, рекламодатели не видят большой заинтересованности в этом протоколе.

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