Зашифрованы ли заголовки HTTPS?
При отправке данных по HTTPS я знаю, что контент зашифрован, однако я слышу неоднозначные ответы о том, зашифрованы ли заголовки или какая часть заголовка зашифрована.
Какая часть заголовков HTTPS являются зашифрована?
Включая URL-адреса запросов GET / POST, файлы cookie и т. д.
Ответы 8
Весь лот зашифрован † - все заголовки. Вот почему SSL на vhosts работает не очень хорошо - вам нужен выделенный IP-адрес, потому что заголовок Host зашифрован.
† Стандарт идентификации имени сервера (SNI) означает, что имя хоста не может быть зашифровано, если вы используете TLS. Кроме того, независимо от того, используете ли вы SNI или нет, заголовки TCP и IP никогда не шифруются. (Если бы они были, ваши пакеты не были бы маршрутизируемыми.)
@Greg, Поскольку шлюз vhost авторизован, не мог ли шлюз их расшифровать, наблюдать за заголовком Host, а затем определить, на какой хост отправлять пакеты?
Сам URL-адрес Afaik не зашифрован.
@Teddu, что вы имеете в виду под "сам URL не зашифрован". Он зашифрован, поскольку является частью заголовка.
Если Fiddler используется для перехвата связи https, он все равно отображает некоторые заголовки, почему? В частности, когда подключение к Интернету осуществляется через прокси-сервер, который требует аутентификации, он отображает заголовок Proxy-Authorization при повторной отправке запроса после получения 407 при первой отправке.
@Bochen, как и Пегас. Если вы находитесь на любом конце туннеля HTTPS, вы можете видеть все. Точно так же я могу видеть что угодно в инструментах разработчика браузера.
При использовании SSL шифрование осуществляется на транспортном уровне, поэтому оно выполняется до отправки запроса.
Итак, все в запросе зашифровано.
Поскольку SSL имеет место на транспортном уровне, а назначение адреса назначения в пакетах (в заголовке) происходит на сетевом уровне (который находится ниже транспортного уровня), то как же зашифровываются заголовки?
@PrateekJoshi Потому что HTTP-заголовки находятся на уровне приложения и поэтому по умолчанию зашифрованы из-за шифрования нижнего уровня / уровня предка.
Заголовки полностью зашифрованы. Единственная информация, передаваемая по сети «в открытом виде», связана с настройкой SSL и обменом ключами D / H. Этот обмен тщательно разработан, чтобы не передавать какую-либо полезную информацию злоумышленникам, и после того, как он произошел, все данные зашифровываются.
Не все настройки SSL включают DH
Чтобы быть немного педантичным: IP-адрес клиента и сервера, имя хоста сервера и сигналы об их реализациях SSL полезны для перехватчиков и видны.
HTTPS (HTTP через SSL) отправляет весь HTTP-контент через SSL-туннель, в HTTP-контент, и заголовки также зашифровываются.
В HTTP версии 1.1 добавлен специальный метод HTTP, CONNECT, предназначенный для создания туннеля SSL, включая необходимое подтверждение протокола и настройку криптографии. После этого все обычные запросы отправляются завернутыми в туннель SSL, включая заголовки и тело.
Когда используется CONNECT для создания туннеля SSL?
@curiousguy tools.ietf.org/html/rfc7231#section-4.3.6
Новый ответ на старый вопрос, извините. Я думал, что добавлю свои 0,02 доллара
OP спросил, были ли заголовки зашифрованы.
Они: в пути.
Они НЕ: когда не в пути.
Таким образом, URL-адрес вашего браузера (и в некоторых случаях заголовок) может отображать строку запроса (которая обычно содержит наиболее важные детали) и некоторые детали в заголовке; браузеру известна некоторая информация заголовка (тип содержимого, юникод и т. д.); а история браузера, управление паролями, избранное / закладки и кешированные страницы будут содержать строку запроса. Журналы сервера на удаленном конце могут также содержать строку запроса, а также некоторые сведения о содержимом.
Кроме того, URL-адрес не всегда безопасен: домен, протокол и порт видны - в противном случае маршрутизаторы не знают, куда отправлять ваши запросы.
Кроме того, если у вас есть прокси-сервер HTTP, прокси-сервер знает адрес, обычно он не знает полной строки запроса.
Так что, если данные перемещаются, они обычно защищены. Если он не в пути, он не зашифрован.
Не придирчиво, но данные в конце также расшифровываются, и их можно анализировать, читать, сохранять, пересылать или отбрасывать по желанию. И вредоносное ПО на любом конце может делать снимки данных, входящих (или выходящих) из протокола SSL - например, (плохой) Javascript внутри страницы внутри HTTPS, который может тайно выполнять http (или https) вызовы на веб-сайты, ведущие журналы (поскольку доступ к локальному жесткому диску часто ограничен и бесполезен).
Кроме того, файлы cookie не шифруются по протоколу HTTPS. Разработчикам, желающим хранить конфиденциальные данные в файлах cookie (или где-либо еще), необходимо использовать собственный механизм шифрования.
Что касается кеширования, большинство современных браузеров не кэшируют страницы HTTPS, но этот факт не определяется протоколом HTTPS, он полностью зависит от разработчика браузера, который не кэширует страницы, полученные через HTTPS.
Так что, если вас беспокоит обнюхивание пакетов, вы, вероятно, в порядке. Но если вас беспокоят вредоносные программы или кто-то, пробирающийся через вашу историю, закладки, файлы cookie или кеш, вы еще не вышли из воды.
Я знаю, что хорошие ответы находятся наверху, но здесь снова вставляется информация неисправен. Домен нет видим, если не используется SNI. Протокол, отличный от IP и TCP, является видимым нет. Вы не можете сказать, использую ли я HTTP 1.1, SPDY или HTTP2. То, что видно на двух конечных точках, не имеет значения, поскольку цель шифрования - не сделать вещи невидимый, а сделать только видимый доверенными сторонами. Таким образом, в вопросе подразумеваются конечные точки, и примерно 2/3 вашего ответа можно удалить. Информация о прокси должна быть такой: если вы используете прокси HTTPS, то это имеет доступ ко всему.
В вашей ссылке конкретно указано, что файлы cookie зашифрованы: «Соединение посетителя зашифровано, скрывая URL-адреса, файлы cookie и другие конфиденциальные метаданные».
Да, это правильно. Файлы cookie зашифровываются во время передачи, но когда они попадают в браузер, они не шифруются протоколом SSL. Разработчик может зашифровать данные cookie, но это выходит за рамки SSL.
@DylanYoung SSL = безопасный уровень разъем; TLS = уровень безопасности транспорт. Шифрование осуществляется на уровне сокета (соединения) или, другими словами, на транспортном уровне, а не сохраняется в браузере для каждой базы данных домена.
@Wigwam Чувствительные к безопасности файлы cookie HTTP почти всегда являются непрозрачными ссылками (обычно это криптографически стойкое случайное число) на запись в базе данных сервера аутентифицированных сеансов. Таким образом, шифрование этого бессмысленного идентификатора в большинстве случаев принесет дополнительную сложность.
Любопытный: да, я знаю. В ответе говорится, что они не зашифрованы с помощью https (что подразумевает ssl). Они есть. Они не зашифрованы в браузере. Ни заголовки, ни какой-либо контент (или, если они есть, они кажутся банально расшифрованными).
URL-адрес также зашифрован, у вас действительно есть только IP, порт и, если SNI, имя хоста, которые не зашифрованы.
Даже если SNI не поддерживается, посредник, способный перехватывать HTTP-соединения, часто также может отслеживать вопросы DNS (большая часть перехвата выполняется рядом с клиентом, как на пиратском пользовательском маршрутизаторе). Таким образом, они смогут видеть имена DNS.
Да, заголовки зашифрованы. Написано здесь.
Everything in the HTTPS message is encrypted, including the headers, and the request/response load.
Википедия - это не спецификация, которую вы должны цитировать.
Заголовки HTTP по HTTPS зашифрованы, но не сжимаются по протоколу HTTP (даже если тело зашифровано). Это делает их менее уязвимыми для атак, связанных со сжатием, таких как BEAST.