Записывает ли ssl маркер-носитель в заголовке? [Дубликат]

Question

Записывает ли ssl маркер-носитель в заголовке? [Дубликат]

content

см. демо на: http://jsfiddle.net/MohammadDayeh/HrZLC/

text-align: center; работает с элементом position: absolute при добавлении left: 0; right: 0;

437

ssl xamarin https oauth token

задан Prasad 10 January 2014 в 22:55

8 ответов

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

48

ответ дан AviD 20 August 2018 в 23:19

1

Когда CONNECT используется для создания SSL-туннеля? – curiousguy 18 July 2018 в 14:49

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

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

40

ответ дан blowdart 20 August 2018 в 23:19

1

Поскольку SSL имеет место на транспортном уровне, а назначение адреса назначения в пакетах (в заголовке) происходит на сетевом уровне (который ниже транспорта), то как шифруются заголовки? – Prateek Joshi 10 February 2017 в 10:26
2

@PrateekJoshi Поскольку HTTP-заголовки живут на прикладном уровне и поэтому по умолчанию зашифровываются из-за зашифрованного слоя ниже / предок. – Aquarelle 26 April 2017 в 03:53

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

33

ответ дан CMS 20 August 2018 в 23:19

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

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

15

ответ дан keypress 20 August 2018 в 23:19

1

Википедия - это не спецификация, которую вы должны цитировать. – Aran Mulholland 10 October 2017 в 13:53

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

85

ответ дан mdb 20 August 2018 в 23:19

1

Не все настройки SSL включают DH – Dori 6 May 2016 в 20:25
2

Быть немного педантичным: IP-адрес клиента и сервера, имя хоста сервера и сигналы об их реализациях SSL полезны для подслушивания и видны. – poolie 26 November 2016 в 23:17

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

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

Они: в пути.

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

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

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

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

Итак, если данные движутся, они в целом защищены. Если он не находится в пути, он не зашифрован.

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

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

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

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

44

ответ дан Wigwam 20 August 2018 в 23:19

1

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

2

Я поддерживаю свой ответ. https.cio.gov/faq – Wigwam 16 November 2017 в 16:38

3

В вашей ссылке указано, что файлы cookie шифруются: «Соединение пользователя зашифровывается, затушевывает URL-адреса, файлы cookie и другие чувствительные метаданные». – DylanYoung 30 November 2017 в 18:14

4

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

5

@DylanYoung SSL = защищенный слой socket ; TLS = транспорт уровень безопасности. Шифрование выполняется на уровне сокета (соединения) или другим способом на транспортном уровне не храниться в браузере на базе данных домена. – curiousguy 18 July 2018 в 14:33

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

6

ответ дан xxiao 20 August 2018 в 23:19
поделиться

1

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

Другие вопросы по тегам:
ssl xamarin https oauth token

Похожие вопросы:

30
C #: После копирования класса & ldquo; this & rdquo; ключевое слово выбрасывает ошибку [дубликат] - 7 October 2014 09:10

30
HttpClient.GetAsync Throws NullReferenceException [дубликат] - 3 September 2017 16:06

30
Сертификат SSL отклонен при попытке доступа к GitHub через HTTPS через брандмауэр - 18 April 2014 20:03

29
Ошибки SSL для всех команд pip [duplicate] - 3 October 2014 16:04

29
как вернуть результат в node.js? [Дубликат] - 15 March 2018 06:12

23
Проверьте сетевое подключение и скорость подключения к сети в xamarin, android [duplicate] - 11 August 2011 13:57

21
Проблема с подтверждением SSL. Пожалуйста, найдите журналы ниже [duplicate] - 16 January 2015 13:36

Когда CONNECT используется для создания SSL-туннеля? — curiousguy, 18 July 2018 в 14:49
Поскольку SSL имеет место на транспортном уровне, а назначение адреса назначения в пакетах (в заголовке) происходит на сетевом уровне (который ниже транспорта), то как шифруются заголовки? — Prateek Joshi, 10 February 2017 в 10:26
@PrateekJoshi Поскольку HTTP-заголовки живут на прикладном уровне и поэтому по умолчанию зашифровываются из-за зашифрованного слоя ниже / предок. — Aquarelle, 26 April 2017 в 03:53
Википедия - это не спецификация, которую вы должны цитировать. — Aran Mulholland, 10 October 2017 в 13:53
Быть немного педантичным: IP-адрес клиента и сервера, имя хоста сервера и сигналы об их реализациях SSL полезны для подслушивания и видны. — poolie, 26 November 2016 в 23:17
Я знаю, что хорошие ответы сверху, но это снова вставляет неисправную информацию. Домен отображается not , если не используется SNI. Протокол, отличный от IP и TCP, отображается not . Вы не можете определить, использую ли я HTTP 1.1, SPDY или HTTP2. То, что видно на двух конечных точках, не имеет значения, поскольку цель шифрования заключается не в том, чтобы сделать вещи невидимыми , а для того, чтобы доверять сторонам только видимые . Таким образом, конечные точки подразумеваются в вопросе, и около 2/3 вашего ответа могут быть удалены. Прокси-информация должна быть: если вы используете прокси-сервер HTTPS, то он имеет доступ ко всем . — Melvyn, 22 December 2016 в 17:45
Я поддерживаю свой ответ. https.cio.gov/faq — Wigwam, 16 November 2017 в 16:38
В вашей ссылке указано, что файлы cookie шифруются: «Соединение пользователя зашифровывается, затушевывает URL-адреса, файлы cookie и другие чувствительные метаданные». — DylanYoung, 30 November 2017 в 18:14
Да это верно. Файлы cookie шифруются во время транзита, но как только они попадают в браузер, они не шифруются протоколом SSL. Разработчик может зашифровать данные cookie, но это выходит за рамки протокола SSL. — Wigwam, 1 December 2017 в 16:44
@DylanYoung SSL = защищенный слой socket ; TLS = транспорт уровень безопасности. Шифрование выполняется на уровне сокета (соединения) или другим способом на транспортном уровне не храниться в браузере на базе данных домена. — curiousguy, 18 July 2018 в 14:33
Даже если SNI не поддерживается, посредник, способный перехватывать HTTP-соединения, часто может также контролировать DNS-запросы (большинство перехватов выполняется рядом с клиентом, например, на пиратском пользовательском маршрутизаторе). Таким образом, они смогут видеть имена DNS. — curiousguy, 18 July 2018 в 14:45

score 414 · Accepted Answer

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

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

414

ответ дан JMD 20 August 2018 в 23:19

1

@Greg, Так как шлюз vhost разрешен, не удалось ли их дешифровать, наблюдать за заголовком хоста, а затем определить, какой хост должен отправлять пакеты? – Pacerier 12 December 2014 в 04:31
2

Сам URL Afaik не зашифрован. – Teddy 16 November 2015 в 08:54
3

@Teddu, что вы подразумеваете под «самой URL-адресом, не зашифрован». Он зашифрован, так как он является частью заголовка. – Dmitry Polushkin 2 February 2017 в 16:43
4

Если Fiddler используется для захвата https-связи, он все равно отображает некоторые заголовки, почему? Особенно, когда подключение к Интернету осуществляется через прокси-сервер, который требует аутентификации, он отображает заголовок прокси-авторизации, когда запрос отправляется после получения 407 при первой отправке. – Bochen Lin 9 January 2018 в 22:57