При отправке данных через HTTPS я знаю, что содержимое зашифровано, однако я слышу смешанные ответы о том, зашифрованы ли заголовки или какая часть заголовка зашифрована.
Сколько зашифрованных заголовков HTTPS?
Включая URL-адреса запроса GET/POST, Cookies и т.д.
Вся партия зашифрована † - все заголовки. То почему SSL на vhosts не работает слишком хорошо - вам нужен выделенный IP-адрес, потому что заголовок Host зашифрован.
† Стандарт идентификации сервера (SNI) означает, что имя хоста не может быть зашифровано, если вы используете TLS. Кроме того, если вы используете SNI или нет, заголовки TCP и IP никогда не зашифровываются. (Если они были, ваши пакеты не будут маршрутизироваться.)
Заголовки полностью зашифрованы. Единственная информация, проходящая через сеть "в ясности", связана с настройкой SSL и обменом ключами D/H. Этот обмен тщательно разработан, чтобы не давать какую-либо полезную информацию для подслушивающих устройств, и как только это произошло, все данные зашифрованы.
HTTP-версия 1.1 добавила специальный HTTP-метод CONNECT - предназначенный для создания SSL-туннеля, включая необходимое протокольное квитирование и криптографическую настройку.
После этого регулярные запросы отправляются, завернутые в туннель SSL, заголовки и составные части тела.
Новый ответ на старый вопрос, извините. Я думал, что добавлю свои $.02
ОП спросил, были ли зашифрованы заголовки.
Они: в пути.
Они НЕ: когда не в пути.
Таким образом, ваш URL-адрес браузера (и заголовок, в некоторых случаях) может отображать запрос (который обычно содержит наиболее важные данные) и некоторые детали в заголовке; браузер знает некоторую информацию заголовка (тип контента, юникод и т.д.); история браузера, управление паролями, избранное/закладки и кешированные страницы будут содержать запрос. Журналы сервера на удаленном конце также могут содержать последовательность запросов, а также некоторые детали содержимого.
Кроме того, URL-адрес не всегда безопасен: домен, протокол и порт видны - в противном случае маршрутизаторы не знают, куда отправлять ваши запросы.
Кроме того, если у вас есть HTTP-прокси, прокси-сервер знает адрес, обычно он не знает полного запроса.
Итак, если данные перемещаются, они в целом защищены. Если он не находится в пути, он не зашифрован.
Не выбирать, но данные в конце также дешифруются и могут анализироваться, считываться, сохраняться, пересылаться или удаляться по желанию. И вредоносная программа с обоих концов может принимать моментальные снимки данных, входящих (или выходящих) из протокола SSL, например (плохой) Javascript внутри страницы внутри HTTPS, которая может тайно совершать вызовы http (или https) для ведения журналов веб-сайтов (поскольку доступ к локальному жесткому диску часто ограничено и не полезно).
Кроме того, файлы cookie также не шифруются в соответствии с протоколом HTTPS. Разработчики, желающие хранить конфиденциальные данные в файлах cookie (или где-либо еще в этом случае), должны использовать свой собственный механизм шифрования.
Что касается кэширования, большинство современных браузеров не будут кэшировать HTTPS-страницы, но этот факт не определяется протоколом HTTPS, он полностью зависит от разработчика браузера, чтобы не кэшировать страницы, полученные через HTTPS.
Так что, если вы беспокоитесь об обнюхивании пакетов, вы, вероятно, все в порядке. Но если вы беспокоитесь о вредоносном ПО или о том, что кто-то прокручивает вашу историю, закладки, файлы cookie или кеш, вы еще не вышли из воды.
С SSL шифрование находится на транспортном уровне, поэтому оно выполняется до отправки запроса.
Итак, все в запросе зашифровано.
HTTPS (HTTP over SSL) отправляет весь HTTP-контент через SSL-туннель, поэтому HTTP-контент и заголовки также зашифровываются.
Да, заголовки шифруются. Здесь написано здесь.
Все в сообщении HTTPS зашифровывается, включая заголовки и загрузку запроса/ответа.
URL-адрес также зашифрован, у вас действительно есть только IP-адрес, порт и SNI, имя узла, которое не зашифровано.