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

600

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

Сколько HTTPS заголовки будут зашифрованы?

Включая URL-адреса запроса GET / POST, файлы cookie и т. Д.

— Дэн Герберт
источник

9

Заголовки HTTP через HTTPS зашифрованы, а также не HTTP-Сжатые (даже если тело). Это делает их менее уязвимыми для атак, связанных со сжатием, таких как BEAST

— Нил Макгиган

552

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

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

— Greg
источник

3

@Greg, Так как шлюз vhost авторизован, шлюз не может их расшифровать, наблюдать заголовок хоста, а затем определить, на какой хост отправлять пакеты?

— Pacerier

2

URL-адрес Afaik сам по себе не зашифрован.

— Тедди

4

@Teddu, что вы подразумеваете под "URL-адрес не зашифрован". Он зашифрован, так как является частью заголовка.

— Дмитрий Полушкин

1

Если Fiddler используется для захвата HTTPS-связи, он по-прежнему отображает некоторые заголовки, почему? В частности, когда интернет-соединение осуществляется через прокси-сервер, который требует аутентификации, он отображает заголовок Proxy-Authorization, когда запрос повторно отправляется после того, как он получает 407 при первой отправке.

— Бочен Лин

1

@ Бочен так же, как Пегас. Если вы находитесь на любом конце туннеля HTTPS, то вы можете видеть все. Точно так же я могу видеть что-либо в браузере devtools.

— Nux

97

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

— MDB
источник

4

Не все настройки SSL связаны с DH

— Дори

30

Чтобы быть немного педантичным: IP-адрес клиента и сервера, имя хоста сервера и сигналы об их реализациях SSL полезны для перехватчиков и являются видимыми.

— Poolie

66

Новый ответ на старый вопрос, извините. Я думал, что добавлю свои $ .02

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

Они в пути.

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

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

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

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

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

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

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

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

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

— Эндрю Дженнингс
источник

20

Я знаю, что хорошие ответы на вершине, но это еще раз вставляет неверную информацию. Домен не виден, если не используется SNI. Протокол, кроме IP и TCP, не виден. Вы не можете сказать, использую ли я HTTP 1.1, SPDY или HTTP2. То, что видно на двух конечных точках, не имеет значения, поскольку цель шифрования состоит не в том, чтобы сделать вещи невидимыми, а в том, чтобы сделать вещи видимыми только для доверенных сторон. Таким образом, конечные точки подразумеваются в вопросе, и около 2/3 вашего ответа могут быть удалены. Информация о прокси должна быть следующей: если вы используете HTTPS-прокси, он имеет доступ ко всему .

— Мелвин

6

В вашей ссылке указано, что файлы cookie зашифрованы: «Соединение посетителя зашифровано, скрывая URL-адреса, файлы cookie и другие конфиденциальные метаданные».

— DylanYoung

1

Да, это правильно. Файлы cookie шифруются во время передачи, но как только они попадают в браузер, они не шифруются протоколом SSL. Разработчик может зашифровать данные cookie, но это выходит за рамки SSL.

— Эндрю Дженнингс

4

@DylanYoung SSL = уровень защищенных сокетов ; TLS = безопасность транспортного уровня. Шифрование выполняется на уровне сокета (соединения) или, иначе говоря, на транспортном уровне, а не хранится в браузере для каждой базы данных домена.

— любопытный парень

@Wigwam Чувствительные к безопасности куки-файлы HTTP - это почти всегда непрозрачные ссылки (обычно это криптографически сильные случайные числа) на запись в базе данных сервера аутентифицированных сеансов. Как таковое шифрование этого бессмысленного идентификатора в основном принесет дополнительную сложность.

— любопытный парень

53

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

— алчный
источник

Когда CONNECT используется для создания туннеля SSL?

— любопытный парень

@curiousguy tools.ietf.org/html/rfc7231#section-4.3.6

— AVP

47

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

Так что все в запросе зашифровано.

— blowdart
источник

Поскольку SSL имеет место на транспортном уровне, а назначение адреса назначения в пакетах (в заголовке) происходит на сетевом уровне (который находится ниже уровня транспорта), то как шифруются заголовки?

— Пратик Джоши

@PrateekJoshi Поскольку заголовки HTTP находятся на уровне приложения и поэтому по умолчанию шифруются из-за шифрования нижнего уровня / уровня предка.

— Акварель

40

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

— CMS
источник

21

Да, заголовки зашифрованы. Это написано здесь .

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

— нажатие клавиши
источник

37

Википедия - это не спецификация, которую вы должны процитировать.

— Аран Малхолланд

8

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

— xxiao
источник

Даже если SNI не поддерживается, посредник, способный перехватывать HTTP-соединения, часто будет способен также отслеживать вопросы DNS (большая часть перехвата выполняется около клиента, как на пиратском пользовательском маршрутизаторе). Таким образом, они смогут видеть имена DNS.

— любопытный парень