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

Ответ 1

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

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

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

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

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

Подробнее о продолжительности сеансов см. Как долго длится симметричный ключ 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-адрес отправки переходит на URL-адрес https://. На самом деле, пользователи прошли обучение (по крайней мере теоретически), чтобы не отправлять страницы, если они не видят маленькую иконку "блокировки", поэтому даже сама форма должна обслуживаться через 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. Большинство браузеров будут отмечать это как предупреждение о безопасности.

Ответ 2

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

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

• Разрешение HTTP, когда вы должны применять HTTPS
• Получение некоторых ресурсов через HTTP с HTTPS-страницы (например, изображений, IFRAME и т.д.)

• Неправильно ссылайтесь на страницу HTTP с страницы HTTPS - обратите внимание, что это включает в себя "поддельные" страницы, например "about: blank" (я видел, что это используется как заполнители IFRAME), это будет бесполезно и неприятно всплывать предупреждение.

• Веб-сервер, настроенный для поддержки старых, небезопасных версий SSL (например, SSL v2 распространен, но ужасно нарушен) (хорошо, это не совсем проблема программиста, но иногда никто другой не справится с этим...)

• Веб-сервер настроен для поддержки небезопасных наборов шифров (я видел только шифры NULL, которые в основном обеспечивают абсолютно БЕЗ шифрования) (То же самое)

• Самоподписанные сертификаты - не позволяют пользователям проверять идентификатор сайта.

• Запрос учетных данных пользователя на странице HTTP, даже если вы отправляете страницу HTTPS. Опять же, это не позволяет пользователю проверять идентификатор сервера, прежде чем указывать ему свой пароль... Даже если пароль передается зашифрованным, пользователь не знает, находится ли он на фиктивном сайте - или даже если он будет зашифрован.

• Незащищенный файл cookie - связанные с безопасностью файлы cookie (такие как sessionId, токен аутентификации, токен доступа и т.д.) ДОЛЖЕН устанавливаются с помощью набора "безопасных" атрибутов. Это важно! Если он не установлен для защиты, cookie безопасности, например. SessionId может передаваться через HTTP (!) - и злоумышленники могут обеспечить это, и таким образом разрешить захват сеанса и т.д. Пока вы на нем (это не связано напрямую), также установите атрибут HttpOnly на свои файлы cookie (помогает смягчить некоторые XSS).

• Слишком разрешительные сертификаты - говорят, что у вас несколько поддоменов, но не все из них находятся на одном уровне доверия. Например, у вас есть 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).

Однако, если у вас есть общие ресурсы (например, тот же сервер) между вашим сайтом и другим сайтом MORE SENSITIVE, тогда более чувствительный сайт должен устанавливать здесь правила.

Кроме того, пароли (и другие учетные данные), информация о кредитной карте и т.д. должны ВСЕГДА превышать SSL/TLS.

Ответ 3

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

Примечание. Это включает все внешние ресурсы (такие как javascript файлы Google Analytics)!

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

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Ответ 7

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