Что нужно знать разработчику PHP о соединениях https/secure socket layer?

Я почти ничего не знаю, когда дело доходит до того, как и почему https-соединения. Очевидно, что когда я передаю защищенные данные, такие как пароли или особенно информацию о кредитной карте, https является важным инструментом. Хотя что мне нужно об этом знать? Какие самые распространенные ошибки, которые вы видите у разработчиков, когда они внедряют его в свои проекты? Бывают ли случаи, когда https — это просто плохая идея? Спасибо!

Решение проблемы

Сертификат HTTPS или Secure Sockets Layer (SSL) обслуживается для сайта и обычно подписывается центром сертификации (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 (если ваш ЦС позволяет вам это делать) и получить сертификат как для «example.com», так и для SAN «.example.com», «example.net» и «.example.net", например.

Формы

Строго говоря, если вы отправляете форму, не имеет значения, не зашифрована ли сама страница формы, если URL-адрес отправки переходит на https:// URL-адрес. На самом деле, пользователи были обучены (по крайней мере, теоретически) не отправлять страницы, пока они не увидят маленький «значок замка», поэтому даже сама форма должна обслуживаться через HTTPS, чтобы получить это.

Трафик и нагрузка на сервер

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

Лучшие практики

• Если вы не просто используете HTTPS для всего сайта, он должен автоматически перенаправляться на HTTPS по мере необходимости. Всякий раз, когда пользователь входит в систему, он должен использовать HTTPS, и если вы используете файлы cookie сеанса, файл cookie должен иметь установленный флаг безопасности. Это предотвращает перехват файла cookie сеанса, что особенно важно, учитывая популярность открытых (незашифрованных) сетей Wi-Fi.




• Любые ресурсы на странице должны исходить из той же схемы, которая используется для страницы. Если вы попытаетесь получить изображения с http://, когда страница загружена с помощью HTTPS, пользователь получит предупреждения системы безопасности. Вы должны либо использовать полные URL-адреса, либо другой простой способ — использовать абсолютные URL-адреса, которые не включают имя хоста (например, src="/images/foo.png"), поскольку они работают для обоих.

  
  
  • Сюда входят внешние ресурсы (например, Google Analytics)
  
  



• Не выполняйте POST (отправку формы) при переходе с HTTPS на HTTP. Большинство браузеров помечают это как предупреждение системы безопасности.