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

https://stackoverflow.com/questions/64631

09-06-2019
|

Вопрос

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

Решение

Сертификат HTTPS, или Secure Sockets Layer (SSL), предоставляется для сайта и обычно подписывается Центром сертификации (CA), который фактически является доверенной третьей стороной, которая проверяет некоторые основные сведения о вашем сайте и сертифицирует его для использования в браузерах.Если ваш браузер доверяет центру сертификации, то он доверяет любым сертификатам, подписанным этим центром сертификации (это называется цепочкой доверия).

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

Клиент (браузер) выполняет "рукопожатие", при котором запрашивает открытый ключ сервера и идентификацию.
- На этом этапе браузер может проверить правильность (совпадает ли название сайта?является ли диапазон дат текущим?подписан ли он центром сертификации, которому он доверяет?).Он даже может связаться с центром сертификации и убедиться, что сертификат действителен.
Клиент создает новый предварительный главный секрет, который шифруется с использованием открытого ключа сервера (поэтому только сервер может его расшифровать) и отправляется на сервер
Сервер и клиент используют этот предварительный главный секрет для генерации главного секрета, который затем используется для создания симметричного сеансового ключа для фактического обмена данными
Обе стороны отправляют сообщение о том, что они завершили рукопожатие
Затем сервер обрабатывает запрос в обычном режиме, а затем шифрует ответ с помощью сеансового ключа

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

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

Подробнее о продолжительности сеансов см. Как долго действует симметричный ключ HTTPS?

Сертификаты и имена хостов

Сертификатам присваивается общее имя (CN), которое для HTTPS является доменным именем.ЦН должен совпадать, например, справку с ТН "example.com" не будет соответствовать домене "www.example.com", а пользователи получат предупреждение в браузере.

До того, как НЮХАТЬ, не было возможности разместить несколько доменных имен на одном IP-адресе.Поскольку сертификат извлекается еще до того, как клиент отправит фактический HTTP-запрос, а HTTP-запрос содержит Хост:строка заголовка, которая сообщает серверу, какой URL использовать, у сервера нет возможности узнать, какой сертификат обслуживать для данного запроса.SNI добавляет имя хоста к части TLS-квитирования, и поэтому, пока оно поддерживается как на клиенте, так и на сервере (а в 2015 году оно широко поддерживается), сервер может выбрать правильный сертификат.

Даже без SNI одним из способов обслуживания нескольких имен хостов является использование сертификатов, которые включают альтернативные имена субъектов (SANS), которые по сути являются дополнительными доменами, для которых действителен сертификат.Например, 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-адресе и не имеете двух сертификатов, он получит сообщение об ошибке сертификата.

Конечно, вы можете использовать как подстановочный знак, так и SANS (если ваш центр сертификации позволяет вам это делать) и получить сертификат как для "example.com", так и с SANS ".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).
Не делайте сообщений (отправки формы) при переходе с HTTPS на HTTP.Большинство браузеров отметят это как предупреждение безопасности.

Другие советы

Я не собираюсь углубляться в SSL в целом, gregmac проделал отличную работу над этим, смотрите Ниже ;-).

Тем не менее, некоторые из наиболее распространенных (и критических) ошибок, допущенных (не конкретно PHP) в отношении использования SSL / TLS:

Разрешать HTTP, когда вы должны применять HTTPS
Извлечение некоторых ресурсов по протоколу HTTP со страницы HTTPS (например,изображения, IFRAMEs и т.д.)
Непреднамеренное перенаправление на HTTP-страницу со страницы HTTPS - обратите внимание, что сюда входят "поддельные" страницы, такие как "about: blank" (я видел, как это использовалось в качестве заполнителей IFRAME), это приведет к ненужному и неприятному всплывающему предупреждению.
Веб-сервер, настроенный на поддержку старых, небезопасных версий SSL (напримерSSL v2 распространен, но ужасно сломан) (ладно, это не совсем проблема программиста, но иногда никто другой с этим не справится ...)
Веб-сервер, настроенный на поддержку незащищенных наборов шифров (я видел только используемые нулевые шифры, которые в принципе не обеспечивают абсолютно никакого шифрования) (то же самое)
Самозаверяющие сертификаты - не позволяет пользователям проверять подлинность сайта.
Запрашивает учетные данные пользователя со страницы HTTP, даже при отправке на страницу HTTPS.Опять же, это не позволяет пользователю подтвердить личность сервера, ПРЕЖДЕ чем предоставлять ему свой пароль...Даже если пароль передается в зашифрованном виде, у пользователя нет возможности узнать, находится ли он на поддельном сайте - или даже будет ли он зашифрован.
Незащищенные файлы cookie - файлы cookie, связанные с безопасностью (такие как идентификатор сеанса, токен аутентификации, токен доступа и т.д.) ДОЛЖЕН должен быть установлен с набором атрибутов "secure".Это очень важно!Если для него не задано значение secure, файл cookie безопасности, напримерSessionID, может быть передан по HTTP (!) - и злоумышленники могут гарантировать, что это произойдет - и, таким образом, разрешить перехват сеанса и т.д.Пока вы этим занимаетесь (хотя это и не связано напрямую), установите атрибут HttpOnly и для ваших файлов cookie (помогает смягчить некоторые ошибки).
Чрезмерно разрешительные сертификаты - допустим, у вас есть несколько поддоменов, но не все из них имеют одинаковый уровень доверия.Например, у вас есть www.yourdomain.com, dowload .yourdomain.com и publicaccess.yourdomain.com .Так что вы могли бы подумать о том, чтобы использовать подстановочный сертификат....НО у вас также есть secure.yourdomain.com или finance.yourdomain.com - даже на другом сервере.publicaccess.yourdomain.com после этого вы сможете выдавать себя за secure.yourdomain.com ....Хотя могут быть случаи, когда это нормально, обычно вам требуется некоторое разделение привилегий...

Это все, что я могу вспомнить прямо сейчас, возможно, отредактирую это позже...

Что касается того, когда это ПЛОХАЯ идея использовать SSL / TLS - если у вас есть общедоступная информация, которая НЕ предназначена для определенной аудитории (будь то отдельный пользователь или зарегистрированные участники), И вы не особенно заинтересованы в том, чтобы они извлекали ее конкретно из надлежащего источника (напримерзначения биржевого тикера ДОЛЖНЫ поступать из аутентифицированного источника ...) - тогда нет реальной причины нести накладные расходы (и не только на производительность...dev/test/cert/etc).

Однако, если у вас есть общие ресурсы (например,тот же сервер) между вашим сайтом и другим БОЛЕЕ КОНФИДЕНЦИАЛЬНЫМ сайтом, тогда более конфиденциальный сайт должен устанавливать здесь правила.

Кроме того, пароли (и другие учетные данные), данные кредитной карты и т.д. Всегда должны передаваться по протоколу SSL / TLS.

Убедитесь, что при использовании HTTPS-страницы все элементы на странице поступают с HTTPS-адреса.Это означает, что элементы должны иметь относительные пути (например"/images/banner.jpg"), чтобы протокол был унаследован, или чтобы вам нужно было выполнять проверку на каждой странице, чтобы найти протокол, и использовать его для всех элементов.

Примечание:Сюда входят все внешние ресурсы (например, файлы JavaScript Google Analytics)!

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

Я бы сказал, что наиболее распространенными ошибками при работе с сайтом с поддержкой SSL являются

Сайт ошибочно перенаправляет пользователей на http со страницы как https
Сайт не переключается автоматически на https, когда это необходимо
Изображения и другие ресурсы на странице https загружаются по протоколу http, что вызовет предупреждение системы безопасности браузера.Убедитесь, что все ресурсы используют полные URI, указывающие https.
Сертификат безопасности работает только для одного поддомена (например, www), но на самом деле ваш сайт использует несколько поддоменов.Обязательно получите подстановочный сертификат, если он вам понадобится.

Я бы предложил в любое время Любой пользовательские данные хранятся в базе данных и передаются по протоколу https.Учитывайте это требование, даже если данные пользователя являются обычными, поскольку даже многие из этих обычных данных используются этим пользователем для идентификации себя на других веб-сайтах.Рассмотрите все случайные контрольные вопросы, которые вам задает ваш банк (например, на какой улице вы живете?).Это можно очень легко извлечь из адресных полей.В этом случае данные - это не то, что вы считаете паролем, но с таким же успехом это могло бы быть.Кроме того, вы никогда не сможете предвидеть, какие пользовательские данные будут использованы для секретного вопроса в другом месте.Вы также можете ожидать, что с интеллектом среднестатистического веб-пользователя (вспомните вашу бабушку) этот лакомый кусочек информации может составлять часть пароля этого пользователя где-то в другом месте.

Один указатель, если вы используете https

сделайте это так, чтобы, если пользователь вводит http://www.website-that-needs-https.com/etc/yadda.php они будут автоматически перенаправлены на https://www.website-that-needs-https.com/etc/yadda.php (личная мозоль для домашних животных)

Однако, если вы просто создаете обычную веб-страницу в формате html, это будет, по сути, односторонняя передача информации с сервера пользователю, не беспокойтесь об этом.

Здесь все очень хорошие чаевые...но я просто хочу кое-что добавить..
Я видел несколько сайтов, которые предоставляют вам страницу входа по http и перенаправляют вас на https только после того, как вы разместите свое имя пользователя / пароль..Это означает, что имя пользователя передается в открытом виде до установления https-соединения..

Короче говоря, создайте страницу, на которой вы входите в систему с помощью ssl, вместо публикации на странице ssl.

Я обнаружил, что пытаюсь <link> обращение к несуществующей таблице стилей также вызывало предупреждения безопасности.Когда я использовал правильный путь, появился значок блокировки.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow