Введение

Метод веб-шифрования, аналогичный протоколу HTTPS, (S HTTP) — устаревшая альтернатива протоколу HTTPS для шифрования веб-коммуникаций, осуществляемых в Интернете. Он был разработан Эриком Рескорлой и Алланом М. Шиффманом в EIT в 1994 году и опубликован в 1999 году как S HTTP. Хотя S HTTP первым появился на рынке, доминирование Netscape на рынке браузеров привело к тому, что HTTPS стал де-факто стандартом для защиты веб-коммуникаций.

Сравнение с HTTP через TLS (HTTPS)

S HTTP шифрует только данные передаваемой страницы и отправляемые данные, такие как поля POST, оставляя инициацию протокола без изменений. Благодаря этому S HTTP можно использовать одновременно с HTTP (незащищенным) на одном и том же порту, поскольку незашифрованный заголовок определяет, зашифрована ли остальная часть передачи. В отличие от этого, HTTP over TLS оборачивает всю связь в протокол Transport Layer Security (TLS; ранее SSL), поэтому шифрование начинается до отправки каких-либо данных протокола. Это создает проблему "курица и яйцо" при определении, какое DNS-имя было предназначено для запроса. Это означает, что реализации HTTPS без поддержки Server Name Indication (SNI) требуют отдельный IP-адрес для каждого DNS-имени, а все реализации HTTPS требуют отдельный порт (обычно 443 вместо стандартного 80 для HTTP) для однозначного использования шифрования (в большинстве браузеров рассматривается как отдельная схема URI, https://). Как задокументировано в RFC 2817, HTTP также может быть защищен путем реализации заголовков HTTP/1.1 Upgrade и обновления до TLS. Запуск HTTP через TLS, согласованный таким образом, не имеет тех же последствий, что и HTTPS, в отношении виртуального хостинга на основе имени (не требуется дополнительных IP-адресов, портов или URI). Однако, лишь немногие реализации поддерживают этот метод. В S HTTP желаемый URL не передается в заголовках открытого текста, а остается пустым; другой набор заголовков присутствует внутри зашифрованного полезной нагрузки. В HTTP over TLS все заголовки находятся внутри зашифрованной полезной нагрузки, и серверное приложение обычно не имеет возможности корректно восстановиться после критических ошибок TLS (включая "сертификат клиента не доверенный" и "срок действия сертификата клиента истек").