Войти
Протокол защищенной передачи гипертекста (S-HTTP ) является устаревшей альтернативой протоколу HTTPS для шифрования веб коммуникаций, передаваемых по HTTP. Он был разработан Эриком Рескорла и Алланом М. Шиффманом и опубликован в 1999 году как RFC 2660.
Веб-браузеры обычно используют HTTP для связи с веб-серверами, отправляя и получая информацию без шифрование. Для конфиденциальных транзакций, таких как Интернет электронная коммерция или онлайн-доступ к финансовым счетам, браузер и сервер должны зашифровать эту информацию. HTTPS и S-HTTP были определены в середине 1990-х годов для удовлетворения этой потребности. S-HTTP использовался веб-сервером Spyglass, в то время как Netscape и Microsoft поддерживали HTTPS, а не S-HTTP, что привело к тому, что HTTPS стал де-факто стандартный механизм для защиты веб-коммуникаций.
S-HTTP шифрует только данные обслуживаемой страницы и отправленные данные, такие как поля POST, оставляя инициирование протокола неизменным. Из-за этого S-HTTP можно использовать одновременно с HTTP (незащищенным) на том же порту, поскольку незашифрованный заголовок будет определять, будет ли зашифрована остальная часть передачи.
Напротив, HTTP поверх TLS обертывает всю связь в рамках Transport Layer Security (TLS; ранее SSL), поэтому шифрование начинается до отправки каких-либо данных протокола. Это создает проблему виртуального хостинга на основе имен «курица и яйцо» с определением, какое имя DNS было предназначено для запроса.
Это означает, что реализации HTTPS без поддержки Server Name Indication (SNI) требуют отдельного IP-адреса для каждого имени DNS, а для всех реализаций HTTPS требуется отдельный порт (обычно 443 по сравнению со стандартом HTTP 80). для однозначного использования шифрования (рассматривается в большинстве браузеров как отдельная схема URI , https: //).
Как описано в RFC 2817, HTTP также может быть защищен путем реализации заголовков обновления HTTP / 1.1 и обновления до TLS. Выполнение HTTP через TLS, согласованное таким образом, не влияет на HTTPS в отношении виртуального хостинга на основе имен (без дополнительных IP-адресов, портов или пространства URI), однако этот метод поддерживается немногими реализациями.
В S-HTTP желаемый URL-адрес не передается в заголовках открытого текста, а остается пустым; другой набор заголовков присутствует внутри зашифрованной полезной нагрузки. В HTTP через TLS все заголовки находятся внутри зашифрованной полезной нагрузки, и серверное приложение обычно не имеет возможности корректно восстановиться после фатальных ошибок TLS (включая «сертификат клиента не является доверенным» и «сертификат клиента истек»).
