Зашифрованы ли заголовки HTTPS?

при отправке данных по HTTPS я знаю, что содержимое зашифровано, однако я слышу смешанные ответы о том, зашифрованы ли заголовки или какая часть заголовка зашифрована.

сколько заголовков HTTPS are шифровать?

включая URL-адреса запросов GET/POST, Cookies и т. д.

8 ответов


все шифруется - все заголовки. Вот почему SSL на vhosts работает не слишком хорошо - вам нужен выделенный IP-адрес, потому что заголовок Хоста зашифрован.

стандарт идентификации имени сервера (SNI) означает, что имя хоста не может быть зашифровано, если вы используете TLS. Кроме того, независимо от того, используете ли вы SNI или нет, заголовки TCP и IP никогда не шифруются. (Если бы они были, ваши пакеты не были бы маршрутизируемыми.)


заголовки полностью зашифрованы. Единственная информация, идущая по сети "в чистом виде", связана с настройкой SSL и обменом ключами D/H. Этот обмен тщательно разработан, чтобы не дать никакой полезной информации подслушивающим, и как только он состоялся, все данные шифруются.


HTTP версии 1.1 добавлен специальный метод HTTP, CONNECT-предназначен для создания туннеля SSL, включая необходимое рукопожатие протокола и криптографическую настройку.
После этого все регулярные запросы отправляются, завернутые в туннель SSL, заголовки и тело включительно.


новый ответ на старый вопрос, Извините. Я решил добавить свои $.02

OP спросил, зашифрованы ли заголовки.

Они находятся: в пути.

Они не когда не в пути.

таким образом, URL вашего браузера (и заголовок, в некоторых случаях) может отображать строку запроса (которая обычно содержит наиболее чувствительные детали) и некоторые детали в заголовке; браузер знает некоторую информацию заголовка (тип контента, Юникод и т. д.); и историю браузера, Управление паролями, Избранное / Закладки и кэшированные страницы будут содержать строку запроса. Журналы сервера на удаленном конце также могут содержать строку запроса, а также некоторые сведения о содержимом.

кроме того, URL-адрес не всегда безопасен: домен, протокол и порт видны - в противном случае маршрутизаторы не знают, куда отправлять ваши запросы.

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

Так что если данные перемещаются, они обычно защищены. Если он не в пути, он не зашифрован.

Не nit pick, но данные в конце также расшифровываются и могут быть проанализированы, прочитаны, сохранены, перенаправлены или отброшены по желанию. И вредоносное ПО на любом конце может делать снимки ввода данных (или выхода) протокола SSL - например, (плохой) Javascript внутри страницы внутри HTTPS, который может тайно совершать http (или https) вызовы веб-сайтов регистрации (так как доступ к локальному жесткому диску часто ограничено и не полезно).

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

Что касается кэша, большинство современных браузеров не будут кэшировать HTTPS-страницы, но этот факт не определяется протоколом HTTPS, это полностью зависит от разработчика браузера, чтобы быть уверенным, что не кэшировать страницы, полученные через ПРОТОКОЛ HTTPS.

Так что если вы беспокоитесь о нюхании пакетов, вы, вероятно, в порядке. Но если вы беспокоитесь о вредоносных программах или кто-то копается в вашей истории, закладках, куки или кэше, вы еще не вышли из воды.


с SSL шифрование находится на транспортном уровне, поэтому оно происходит до отправки запроса.

таким образом, все в запросе зашифровано.


HTTPS (HTTP через SSL) отправляет все содержимое HTTP через SSL tunel, поэтому содержимое HTTP и заголовки также шифруются.


да, заголовки шифруются. Написано здесь.

все в сообщении HTTPS зашифровано, включая заголовки и нагрузку запроса / ответа.


URL также зашифрован, у вас действительно есть только IP, порт и если SNI, имя хоста, которые не зашифрованы.