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

HTTP
Упорство Сжатие HTTPS БЫСТРЫЙ
Методы запроса
ПАРАМЕТРЫ ПОЛУЧАТЬ ГОЛОВА ПОЧТА ПОМЕЩАТЬ УДАЛИТЬ СЛЕД СОЕДИНЯТЬ ПЛАСТЫРЬ
Поля заголовка
Печенье ETag Расположение HTTP-реферер ДНТ X-Forwarded-For
Коды статуса ответа
301 Перемещено навсегда 302 Найдено 303 Смотреть другое 403 Запрещено 404 Не найдено 451 Недоступно по юридическим причинам
Методы контроля доступа безопасности
Базовая аутентификация доступа Дайджест-аутентификация доступа
Уязвимости безопасности
Внедрение HTTP-заголовка Контрабанда HTTP-запросов Разделение HTTP-ответа Загрязнение HTTP-параметров
в т е

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

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

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

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

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

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

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