Включение HTTPS на ваших серверах

Крис Палмер
Chris Palmer

Действия, описанные в этой статье

  1. Создайте пару открытого и закрытого ключей RSA длиной 2048 бит.
  2. Создайте запрос на подпись сертификата (CSR), который внедрит ваш открытый ключ.
  3. Поделитесь своим CSR со своим центром сертификации (CA), чтобы получить окончательный сертификат или цепочку сертификатов.
  4. Установите окончательный сертификат в недоступном через Интернет месте, например в /etc/ssl (Linux и Unix) или там, где этого требует IIS (Windows).

Генерация ключей и запросов на подпись сертификата

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

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

Начнем с создания пары ключей RSA длиной 2048 бит. Меньший ключ, например 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 (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, 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 по электронной почте или что-то еще. Некоторые центры сертификации (или их реселлеры) могут даже автоматизировать некоторые или все процессы (включая, в некоторых случаях, пару ключей и генерацию CSR).

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

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

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

Например, один центр сертификации в настоящее время предлагает такие цены:

  • Стандарт: 16 долларов США в год, действует для сайтов example.com и www.example.com.
  • Подстановочный знак: 150 долларов США в год, действителен для example.com и *.example.com.

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

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

Включите HTTPS на ваших серверах

Включение HTTPS на ваших серверах является важным шагом в обеспечении безопасности ваших веб-страниц.

  • Используйте инструмент настройки сервера Mozilla, чтобы настроить свой сервер для поддержки HTTPS.
  • Регулярно тестируйте свой сайт с помощью удобного теста SSL-сервера Qualys и убедитесь, что вы получили как минимум A или A+.

На этом этапе вы должны принять важное операционное решение. Выберите один из следующих вариантов:

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

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

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

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

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

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

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

Сделайте внутрисайтовые URL-адреса относительными

Теперь, когда вы обслуживаете свой сайт как по HTTP, так и по HTTPS, все должно работать максимально гладко, независимо от протокола. Важным фактором является использование относительных URL-адресов для внутрисайтовых ссылок.

Убедитесь, что внутрисайтовые и внешние URL-адреса не зависят от протокола; то есть убедитесь, что вы используете относительные пути или не используете протокол типа //example.com/something.js .

Проблема возникает, когда вы обслуживаете страницу через HTTPS, которая включает ресурсы HTTP, известные как смешанный контент . Браузеры предупреждают пользователей о том, что вся мощь HTTPS утеряна. Фактически, в случае активного смешанного контента (скриптов, плагинов, CSS, iframe) браузеры часто просто не загружают или не выполняют контент вообще, что приводит к неработающей странице. И помните, совершенно нормально включать ресурсы HTTPS на HTTP-страницу.

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

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

Не
<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>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
Избегайте использования полных внутрисайтовых URL-адресов.

Другими словами, сделайте внутрисайтовые URL-адреса как можно более относительными: либо относительно протокола (отсутствие протокола, начиная с //example.com ), либо относительно хоста (начиная только с пути, например /jquery.js ).

Делать
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
Используйте относительные внутрисайтовые URL-адреса.
Делать
<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>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
Или используйте внутрисайтовые URL-адреса с учетом протокола.
Делать
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
Используйте URL-адреса HTTPS для межсайтовых URL-адресов (где это возможно).

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

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

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

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

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

Перенаправить HTTP на HTTPS

Вам необходимо разместить каноническую ссылку в начале страницы, чтобы сообщить поисковым системам, что HTTPS — лучший способ попасть на ваш сайт.

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

Включите строгую транспортную безопасность и защитите файлы cookie.

На этом этапе вы готовы «заблокировать» использование HTTPS.

  • Используйте строгую транспортную безопасность HTTP (HSTS), чтобы избежать затрат на перенаправление 301.
  • Всегда устанавливайте флажок «Безопасно» для файлов cookie.

Во-первых, используйте Strict Transport Security , чтобы сообщить клиентам, что им всегда следует подключаться к вашему серверу через HTTPS, даже если они следуют ссылке http:// . Это предотвращает такие атаки, как удаление SSL , а также позволяет избежать затрат на 301 redirect , которое мы включили в разделе «Перенаправление HTTP на HTTPS» .

Включите строгую транспортную безопасность HTTP (HSTS), установив заголовок Strict-Transport-Security . На странице HSTS OWASP есть ссылки на инструкции для различного серверного программного обеспечения.

Большинство веб-серверов предлагают аналогичную возможность добавления пользовательских заголовков.

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

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

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

Рейтинг поиска

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

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

Когда уровни контента и приложения хорошо настроены (полезные советы см. в книгах Стива Соудерса ), оставшиеся проблемы с производительностью TLS обычно невелики по сравнению с общей стоимостью приложения. Кроме того, вы можете сократить и амортизировать эти затраты. (Полезные советы по оптимизации TLS и в целом см. в разделе «Высокопроизводительная сеть браузеров» Ильи Григорика.) См. также «Поваренную книгу OpenSSL» Ивана Ристича и Bulletproof SSL And TLS .

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

Заголовки реферера

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

  • Остальные сайты должны перейти на HTTPS. Если реферальные сайты могут заполнить раздел «Включение HTTPS на ваших серверах» данного руководства, вы можете изменить ссылки на своем сайте на их с http:// на https:// или использовать ссылки, относящиеся к протоколу.
  • Чтобы обойти различные проблемы с заголовками Referer, используйте новый стандарт Referrer Policy .

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

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

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

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