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