Безопасный протокол передачи гипертекста

Протокол безопасной передачи гипертекста ( S-HTTP ) — устаревшая альтернатива протоколу HTTPS для шифрования веб -коммуникаций, передаваемых через Интернет. Он был разработан Эриком Рескорлой и Алланом М. Шиффманом из EIT в 1994 году. ^{[ 1 ]} и опубликован в 1999 году как РФК 2660 .

Несмотря на то, что S-HTTP был первым на рынке, ^{[ 2 ]} Доминирование Netscape на рынке браузеров привело к тому, что HTTPS стал фактическим методом защиты веб-коммуникаций.

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

S-HTTP шифрует только данные обслуживаемой страницы и отправленные данные, такие как поля POST, оставляя запуск протокола неизменным. По этой причине S-HTTP может использоваться одновременно с HTTP (незащищенным) на том же порту, поскольку незашифрованный заголовок будет определять, зашифрована ли остальная часть передачи.

Напротив, HTTP поверх TLS оборачивает всю связь в систему безопасности транспортного уровня (TLS; ранее SSL), поэтому шифрование начинается до отправки каких-либо данных протокола. Это создает виртуального хостинга на основе имени проблему «курицы и яйца» , связанную с определением того, какое DNS- имя предназначалось для запроса.

Это означает, что реализации HTTPS без поддержки указания имени сервера (SNI) требуют отдельного IP-адреса для каждого DNS-имени, а для всех реализаций HTTPS требуется отдельный порт (обычно 443 вместо стандартного 80 HTTP). ^{[ 3 ]} для однозначного использования шифрования (в большинстве браузеров рассматривается как отдельная схема URI , https:// ).

Как описано в RFC 2817, HTTP также можно защитить путем реализации заголовков обновления HTTP/1.1 и обновления до TLS. Запуск HTTP через TLS, согласованный таким образом, не имеет последствий HTTPS в отношении виртуального хостинга на основе имени (без дополнительных IP-адресов, портов или пространства URI). Однако лишь немногие реализации поддерживают этот метод.

В S-HTTP желаемый URL-адрес не передается в заголовках открытого текста, а остается пустым; внутри зашифрованной полезной нагрузки присутствует другой набор заголовков. В HTTP через TLS все заголовки находятся внутри зашифрованных полезных данных, и серверное приложение обычно не имеет возможности корректно восстановиться после фатальных ошибок TLS (включая «сертификат клиента не является надежным» и «срок действия сертификата клиента истек»). ^{[ 3 ]}

Ссылки

^ «Протокол безопасной передачи гипертекста» . ietf.org . IETF. Идентификатор Draft-ietf-wts-shttp-01.txt . Проверено 8 февраля 2022 г.
^ Льюис, Питер (12 августа 1994 г.). «Внимание покупателей: Интернет открыт» . Нью-Йорк Таймс . Проверено 8 февраля 2022 г.
^ Jump up to: ^а ^б Том Шелдон (2001). «S-HTTP (протокол безопасной передачи гипертекста)» . Проверено 1 января 2016 г.

Внешние ссылки

RFC 2660 Протокол безопасной передачи гипертекста

[1] «Протокол безопасной передачи гипертекста» . ietf.org . IETF. Идентификатор Draft-ietf-wts-shttp-01.txt . Проверено 8 февраля 2022 г.

[2] Льюис, Питер (12 августа 1994 г.). «Внимание покупателей: Интернет открыт» . Нью-Йорк Таймс . Проверено 8 февраля 2022 г.

[:0-3] Jump up to: ^а ^б Том Шелдон (2001). «S-HTTP (протокол безопасной передачи гипертекста)» . Проверено 1 января 2016 г.

[ 1 ]

[ 2 ]

[ 3 ]