HTTPS, или SSL-сертификат, используется для сайта и обычно подписывается центром сертификации (ЦС), который фактически является доверенной третьей стороной, которая проверяет некоторые базовые сведения о вашем сайте и сертифицирует это для использования в браузерах. Если ваш браузер доверяет CA, то он доверяет любым сертификатам, подписанным этим CA (это называется цепочкой доверия).
Каждый HTTP (или HTTPS) запрос состоит из двух частей: запроса и ответа. Когда вы запрашиваете что-то через HTTPS, в фоновом режиме происходит несколько вещей:
- Клиент (браузер) выполняет «рукопожатие», когда запрашивает открытый ключ и идентификацию сервера.
- В этот момент браузер может проверить правильность (соответствует ли имя сайта? Текущий диапазон дат? Подписано ли оно ЦС, которому доверяет?). Он может даже связаться с центром сертификации и убедиться, что сертификат действителен.
- Клиент создает новый предварительный главный секрет, который шифруется с использованием открытого ключа сервера (так что только сервер может его расшифровать) и отправляется на сервер
- Сервер и клиент оба используют этот предварительный главный секрет для генерации главного секрета, который затем используется для создания симметричного сеансового ключа для фактического обмена данными
- Обе стороны отправляют сообщение о том, что они сделали рукопожатие
- Затем сервер обрабатывает запрос в обычном режиме, а затем шифрует ответ, используя сеансовый ключ
Если соединение остается открытым, для каждого будет использоваться один и тот же симметричный ключ.
Если новое соединение установлено, и обе стороны все еще имеют главный секрет, новые сеансовые ключи могут быть сгенерированы в «сокращенном рукопожатии». Обычно браузер будет хранить главный секрет до тех пор, пока он не будет закрыт, а сервер будет хранить его в течение нескольких минут или нескольких часов (в зависимости от конфигурации).
Подробнее о продолжительности сеансов см. Как долго действует симметричный ключ HTTPS?
Сертификаты и имена хостов
Сертификатам присваивается общее имя (CN), которое для HTTPS является доменным именем. CN должен точно соответствовать, например, сертификат с CN «example.com» НЕ будет соответствовать домену «www.example.com», и пользователи получат предупреждение в своем браузере.
До SNI было невозможно разместить несколько доменных имен на одном IP. Поскольку сертификат выбирается еще до того, как клиент отправляет фактический HTTP-запрос, а HTTP-запрос содержит строку заголовка Host:, которая сообщает серверу, какой URL-адрес использовать, у сервера нет способа узнать, какой сертификат следует использовать для данного запрос. SNI добавляет имя узла к части рукопожатия TLS, и поэтому, пока оно поддерживается как на клиенте, так и на сервере (а в 2015 году оно широко поддерживается), сервер может выбрать правильный сертификат.
Даже без SNI одним из способов обслуживания нескольких имен хостов является использование сертификатов, включающих альтернативные имена субъектов (SAN), которые по сути являются дополнительными доменами, для которых действителен сертификат. Например, Google использует один сертификат для защиты многих своих сайтов.
Другой способ - использовать групповые сертификаты. Можно получить сертификат типа « .example.com», в этом случае «www.example.com» и «foo.example.com» будут действительными для этого сертификата. Однако обратите внимание, что «example.com» не соответствует « .example.com», а также «foo.bar.example.com». Если вы используете «www.example.com» для своего сертификата, вы должны перенаправить кого-либо с «example.com» на «www». сайт. Если они запрашивают https://example.com,, если вы не размещаете его на отдельном IP-адресе и не имеете двух сертификатов, вы получите ошибку сертификата.
Конечно, вы можете смешивать как подстановочные знаки, так и SAN (при условии, что ваш CA позволяет это делать) и получить сертификат как для "example.com", так и для SAN " .example.com", "example .net "и" .example.net ", например.
Форма
Строго говоря, если вы отправляете форму, не имеет значения, если сама страница формы не зашифрована, если отправляемый URL переходит на https: // URL. В действительности, пользователи были обучены (по крайней мере, теоретически) не отправлять страницы, если они не видят маленький «значок замка», поэтому даже сама форма должна быть предоставлена через HTTPS, чтобы получить это.
Трафик и загрузка сервера
HTTPS-трафик намного больше, чем его эквивалентный HTTP-трафик (из-за шифрования и накладных расходов на сертификаты), а также увеличивает нагрузку на сервер (шифрование и дешифрование). Если у вас сильно загруженный сервер, может быть желательно быть очень избирательным в отношении того, какой контент подается с использованием HTTPS.
Лучшие практики
Если вы не просто используете HTTPS для всего сайта, он должен автоматически перенаправить на HTTPS по мере необходимости. Каждый раз, когда пользователь входит в систему, он должен использовать HTTPS, а если вы используете сеансовые куки-файлы, для куки-файла должен быть установлен безопасный флаг . Это предотвращает перехват cookie-файлов сеанса, что особенно важно, учитывая популярность открытых (незашифрованных) сетей Wi-Fi.
Любые ресурсы на странице должны исходить из той же схемы, что и страница. Если вы попытаетесь получить изображения с http: //, когда страница загружена по протоколу HTTPS, пользователь получит предупреждения безопасности. Вы должны либо использовать полностью определенные URL-адреса, либо другой простой способ - использовать абсолютные URL-адреса, которые не включают имя хоста (например, src = "/ images / foo.png"), поскольку они работают для обоих.
- Сюда входят внешние ресурсы (например, Google Analytics)
Не выполнять POST (отправка формы) при переходе с HTTPS на HTTP. Большинство браузеров помечают это как предупреждение системы безопасности.