Зашифрованы ли URL-адреса HTTPS?


1021

Все ли URL зашифрованы при использовании шифрования TLS / SSL (HTTPS)? Я хотел бы знать, потому что я хочу, чтобы все данные URL были скрыты при использовании TLS / SSL (HTTPS).

Если TLS / SSL обеспечивает полное шифрование URL-адреса, мне не нужно беспокоиться о сокрытии конфиденциальной информации от URL-адресов.


76
Возможно, в любом случае плохая идея помещать конфиденциальные данные в URL. Это будет отображаться в адресе браузера тоже плохо, помните? Людям не нравится, если их пароль виден любому, кто случайно заглядывает в экран. Как вы думаете, почему вы должны поместить конфиденциальные данные в URL?
Джалф

43
URL-адреса также хранятся в истории браузера и журналах сервера - если бы я хотел, чтобы мое имя и пароль хранились где-то, их не было бы в этих двух местах.
Писквор покинул здание

47
Например, предположим, я посещаю https://somewhere_i_trust/ways_to_protest_against_the_government/. Тогда URL содержит конфиденциальные данные, а именно предложение, которое я рассматриваю, чтобы выразить протест против моего правительства.
Стив Джессоп

42
Я задавал себе этот вопрос, когда делал HTTP-запрос из нативного (не основанного на браузере) приложения. Я предполагаю, что это может заинтересовать разработчиков мобильных приложений. В этом случае вышеприведенные комментарии (хотя и истинные) не имеют никакого значения (URL не виден, история просмотра отсутствует), поэтому, на мой взгляд, ответ прост: «Да, он зашифрован».
DannyA

23
Для тех, кто думает, что, как только вы HTTPS, никто не знает, куда вы идете, сначала прочтите это: имя хоста сервера (например, example.com) все равно будет пропущено из-за SNI . Это не имеет абсолютно никакого отношения к DNS, и утечка произойдет, даже если вы не используете DNS или не используете зашифрованный DNS.
Pacerier

Ответы:


913

Да, SSL-соединение находится между уровнем TCP и уровнем HTTP. Клиент и сервер сначала устанавливают безопасное зашифрованное TCP-соединение (через протокол SSL / TLS), а затем клиент отправляет HTTP-запрос (GET, POST, DELETE ...) через это зашифрованное TCP-соединение.


98
Стоит отметить, что @Jalf упомянул в комментарии к самому вопросу. Данные URL также будут сохранены в истории браузера, что может быть небезопасным в долгосрочной перспективе.
Майкл Экстранд

20
Не только ПОЛУЧИТЬ или ПОСТ. Также может быть DELETE, PUT, HEAD или TRACE.

4
Да, это может быть проблемой безопасности для истории браузера. Но в моем случае я не использую браузер (также оригинальный пост не упоминал браузер). Использование собственного https-вызова за кулисами в нативном приложении. Это простое решение, обеспечивающее безопасное соединение вашего приложения.
zingle-dingle

28
Однако обратите внимание, что разрешение URL-адреса в DNS, вероятно, не зашифровано. Таким образом, кто-то, отслеживающий ваш трафик, все еще может видеть домен, к которому вы пытаетесь получить доступ.
ChewToy

21
SNI нарушает часть «хоста» SSL-шифрования URL-адресов. Вы можете проверить это самостоятельно с помощью wireshark. Существует селектор для SNI, или вы можете просто просмотреть ваши SSL-пакеты при подключении к удаленному хосту.
cmouse

654

Так как никто не обеспечил захват провода, вот один.
Имя сервера (доменная часть URL-адреса) представлено в ClientHelloпакете в виде простого текста .

Ниже показан запрос браузера:
https://i.stack.imgur.com/path/?some=parameters&go=here

ClientHello SNI См. Этот ответ для более подробной информации о полях версий TLS (их 3, а не версии, каждый из которых содержит номер версии!)

От https://www.ietf.org/rfc/rfc3546.txt :

3.1. Указание имени сервера

[TLS] не предоставляет клиенту механизм, позволяющий сообщать серверу имя сервера, с которым он связывается. Клиентам может быть желательно предоставить эту информацию для облегчения безопасных соединений с серверами, на которых размещено несколько «виртуальных» серверов по одному базовому сетевому адресу.

Чтобы предоставить имя сервера, клиенты МОГУТ включить расширение типа «имя_сервера» в (расширенный) клиент hello.


Короче говоря:

  • FQDN (доменная часть URL-адреса) МОЖЕТ быть передано в открытом виде внутриClientHello пакета , если используется расширение SNI

  • Остальная часть URL ( /path/?some=parameters&go=here) не имеет делового характера, ClientHelloпоскольку URL-адрес запроса является HTTP-компонентом (уровень 7 OSI), поэтому он никогда не будет отображаться при подтверждении связи TLS (уровень 4 или 5). Это будет позже в GET /path/?some=parameters&go=here HTTP/1.1HTTP-запросе, ПОСЛЕ установления безопасного канала TLS.


УПРАВЛЯЮЩЕЕ РЕЗЮМЕ

Доменное имя МОЖЕТ быть передано в открытом виде (если расширение SNI используется в рукопожатии TLS), но URL (путь и параметры) всегда шифруются.


МАРТ 2019 ОБНОВЛЕНИЕ

Спасибо carlin.scott за то, что поднял этот вопрос.

Полезная нагрузка в расширении SNI теперь может быть зашифрована с помощью этого проекта предложения RFC . Эта возможность существует только в TLS 1.3 (как опция, и ее реализация возможна обоими сторонами), и обратной совместимости с TLS 1.2 и ниже не существует.

CloudFlare делает это, и вы можете прочитать больше о внутренностях здесь - Если курица должна быть раньше яйца, куда вы положите курицу?

На практике это означает, что вместо передачи полного доменного имени в виде простого текста (как показано в захвате Wireshark) теперь оно шифруется.

ПРИМЕЧАНИЕ. Это касается аспекта конфиденциальности в большей степени, чем аспект безопасности, поскольку обратный поиск DNS МОЖЕТ в любом случае выявить целевой узел назначения.


37
Идеальный ответ, с полным объяснением от А до Я. Я люблю Исполнительное резюме. Сделал мой день @evilSnobu
oscaroscar

4
Идеальный ответ, upvote! Еще рассмотрим клиентскую часть, поскольку история браузера может быть утечкой. Однако, что касается транспортного уровня, URL-параметры зашифрованы.
Дженс Крейдлер

2
Возможно, вы захотите обновить этот ответ тем фактом, что TLS 1.3 шифрует расширение SNI, а крупнейший CDN делает именно это: blog.cloudflare.com/encrypted-sni. Конечно, анализатор пакетов может просто выполнить обратный просмотр DNS для IP-адреса, к которым вы подключаетесь.
carlin.scott

@evilSnobu, но имя пользователя: пароль. Часть имени пользователя: password@domain.com зашифрована, верно? Таким образом, безопасно передавать конфиденциальные данные в URL, используя https.
Максим Шамихулау

1
Они зашифрованы в сети (при транспортировке), но если какой-либо конец (пользователь или сервер) записывает URL-адрес в текстовый файл и не очищает учетные данные ... теперь это другой разговор.
evilSnobu

159

Как уже отмечалось в других ответах , «URL-адреса» https действительно зашифрованы. Однако ваш DNS-запрос / ответ при разрешении доменного имени, вероятно, нет, и, конечно, если вы используете браузер, ваши URL-адреса также могут быть записаны.


21
И запись URL важна, так как существуют взломы Javascript, которые позволяют совершенно не связанному сайту проверить, есть ли данный URL в вашей истории или нет. Вы можете сделать URL неуязвимым, включив в него длинную случайную строку, но если это общедоступный URL, то злоумышленник может сказать, что он был посещен, а если у него есть короткий секрет, то злоумышленник может на разумной скорости.
Стив Джессоп

8
@SteveJessop, предоставьте ссылку на «
Pacerier

6
@Pacerier: взламывает дату, конечно, но в то время я говорил о таких вещах, как stackoverflow.com/questions/2394890/… . В 2010 году было очень важно, что эти проблемы были расследованы, а атаки усовершенствованы, но на данный момент я не особо слежу за этим.
Стив Джессоп

2
@Pacerier: больше примеров: webdevwonders.com/… , webdevwonders.com/…
Стив Джессоп

1
Вы можете использовать OpenDNS с зашифрованной службой DNS. Я использую его на своем Mac, но обнаружил, что версия Windows не работает должным образом. Это было некоторое время назад, так что теперь это может работать нормально. Для Linux пока ничего. opendns.com/about/innovations/dnscrypt
SPRBRN

101

Весь запрос и ответ зашифрованы, включая URL.

Обратите внимание, что при использовании прокси-сервера HTTP он знает адрес (домен) целевого сервера, но не знает запрошенный путь на этом сервере (т. Е. Запрос и ответ всегда зашифрованы).


1
Вся просьба. Имя хоста отправляется в открытом виде. Все остальное зашифровано.
Сэм Сирри

98

Я согласен с предыдущими ответами:

Чтобы быть явным:

При использовании TLS первая часть URL-адреса ( https://www.example.com/ ) по-прежнему видна при создании соединения. Вторая часть (/ herearemygetparameters / 1/2/3/4) защищена TLS.

Однако есть ряд причин, по которым вам не следует указывать параметры в запросе GET.

Во-первых, как уже упоминалось другими: - утечка через адресную строку браузера - утечка через историю

В дополнение к этому у вас есть утечка URL через http referer: пользователь видит сайт A на TLS, затем щелкает ссылку на сайт B. Если оба сайта находятся на TLS, запрос к сайту B будет содержать полный URL с сайта A в параметр referer запроса. И администратор с сайта B может получить его из файлов журнала сервера B.)


3
@EJP Вы не поняли, что говорит Тобиас. Он говорит, что если вы нажмете ссылку на сайте A, которая приведет вас на сайт B, то сайт B получит URL-адрес реферера. Например, если вы находитесь на siteA.com?u=username&pw=123123 , то siteB.com (ссылка на который находится на странице siteA.com) получит " siteA.com?u=username&pw=123123 " в качестве ссылающейся URL, отправляемый на siteB.com внутри HTTPS браузером. Если это правда, это очень плохо. Это правда, Тобиас?
trusktr

9
@EJP, домен виден из-за SNI, который используют все современные веб-браузеры. Также посмотрите эту диаграмму из EFF, показывающую, что каждый может видеть домен сайта, который вы посещаете. Это не о видимости браузера. Речь идет о том, что видно подслушивающим.
Buge

10
@trusktr: браузеры не должны отправлять заголовок Referer со страниц HTTPS. Это часть спецификации HTTP .
Мартин Гайслер

8
@MartinGeisler, ключевое слово "должен". Браузеры не очень заботятся о «должен» (в отличие от «должен»). По вашей собственной ссылке: «Настоятельно рекомендуется, чтобы пользователь мог выбирать, отправлять ли поле Referer или нет. Например, клиент браузера может иметь переключатель для открытого / анонимного просмотра, который соответственно включит / отключит отправку Реферер и Из информации " . Опс, что и сделал Chrome. За исключением того, что Chrome пропускает Реферер, даже если вы находитесь в режиме инкогнито .
Pacerier

48

Дополнение к полезному ответу от Marc Novakowski - URL хранится в журналах на сервере (например, в / etc / httpd / logs / ssl_access_log), так что если вы не хотите, чтобы сервер поддерживал информацию в течение более длительного времени термин, не помещайте это в URL.


34

Да и нет.

Часть адреса сервера НЕ зашифрована, так как она используется для настройки соединения.

Это может измениться в будущем с зашифрованными SNI и DNS, но с 2018 года обе технологии обычно не используются.

Путь, строка запроса и т. Д. Зашифрованы.

Примечание для запросов GET пользователь по-прежнему сможет вырезать и вставлять URL-адрес из адресной строки, и вы, вероятно, не захотите помещать туда конфиденциальную информацию, которую может увидеть любой, кто смотрит на экран.


8
Я хотел бы добавить +1, но я нахожу вводящее в заблуждение «да и нет» - вы должны изменить это, чтобы просто указать, что имя сервера будет разрешено с использованием DNS без шифрования.
Лоуренс Дол

7
В моем понимании, ОП использует слово URL в правильном смысле. Я думаю, что этот ответ более вводит в заблуждение, поскольку он явно не делает разницы между именем хоста в URL и именем хоста в разрешении DNS.
Гийом

4
URL зашифрован. Каждый аспект транзакции HTTP зашифрован. Не только «все остальное». Период. -1.
Маркиз Лорн

4
@EJP но DNS поиск делает использовать то , что в одной точке части URL, так нетехнических человека, весь URL не шифруется. Нетехнический человек, который просто использует Google.com для поиска нетехнических вещей, не знает, где в конечном итоге находятся данные или как они обрабатываются. Домен, являющийся частью URL-адреса, который посещает пользователь, не на 100% зашифрован, поскольку я, как злоумышленник, могу узнать, какой сайт он посещает. Только / путь URL зашифрован для неспециалистов (неважно, как).
trusktr

6
@EJP, @ trusktr, @ Лоуренс, @ Гийом. Вы все ошибаетесь. Это не имеет ничего общего с DNS. SNI " отправляет имя виртуального домена как часть согласования TLS », поэтому даже если вы не используете DNS или если ваш DNS зашифрован, анализатор все равно может видеть имя хоста ваших запросов.
Pacerier

9

Сторонний наблюдатель, который отслеживает трафик, также может определить посещаемую страницу, проверив ваш трафик и сравнив его с трафиком другого пользователя при посещении сайта. Например, если на сайте было только 2 страницы, одна намного больше другой, тогда сравнение размера передаваемых данных покажет, какую страницу вы посетили. Есть способы, которые могут быть скрыты от сторонних разработчиков, но они не являются нормальным поведением сервера или браузера. Смотрите, например, эту статью из SciRate, https://scirate.com/arxiv/1403.0297 .

В целом, другие ответы верны, хотя на практике этот документ показывает, что посещаемые страницы (например, URL) могут быть определены достаточно эффективно.


Это действительно было бы возможно только на очень маленьких сайтах, и в этих случаях тема / тон / природа сайта, вероятно, была бы примерно одинаковой на каждой странице.
Кэмерон

5
Из цитаты, которую я привел: «Мы представляем атаку с анализом трафика на более чем 6000 веб-страниц, охватывающих развертывания HTTPS 10 широко используемых, ведущих в отрасли веб-сайтов в таких областях, как здравоохранение, финансы, юридические услуги и потоковое видео. Наша атака определяет отдельные страницы в тот же веб-сайт с точностью [...] 89% ". Кажется, ваш вывод о целесообразности неверен.
pbhj

2
Для тех, кто интересуется подробностями об уязвимости такого рода, такие типы атак обычно называют атаками по побочным каналам .
Дэн Бешард

7

Вы также не всегда можете рассчитывать на конфиденциальность полного URL. Например, как это иногда бывает в корпоративных сетях, поставляемые устройства, такие как ПК вашей компании, настраиваются с дополнительным «доверенным» корневым сертификатом, так что ваш браузер может спокойно доверять проверке прокси-сервера (посредника) трафика https. , Это означает, что полный URL открыт для проверки. Обычно это сохраняется в журнале.

Кроме того, ваши пароли также раскрыты и, вероятно, зарегистрированы, и это еще одна причина, чтобы использовать одноразовые пароли или часто менять свои пароли.

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

Один пример настройки проверки описан здесь Checkpoint . Таким же образом можно настроить старое интернет-кафе с использованием прилагаемых компьютеров.


6

Ссылка на мой ответ на дублирующий вопрос . URL-адрес доступен не только в истории браузеров, журналах на стороне сервера, но и в виде заголовка HTTP Referer, который, если вы используете сторонний контент, предоставляет URL-адрес источникам, находящимся вне вашего контроля.


Обеспечение ваших сторонних вызовов - это тоже HTTPS, хотя это не проблема, верно?
Лиам

3
Он будет зашифрован с сертификатом третьих лиц, чтобы они могли видеть URL
JoshBerke

5

Сейчас 2019 год, и TLS v1.3 был выпущен. Согласно Cloudflare, SNI может быть зашифрован благодаря TLS v1.3. Итак, я сказал себе здорово! давайте посмотрим, как это выглядит в TCP-пакетах cloudflare.com Итак, я поймал пакет рукопожатия "hello client" из ответа сервера cloudflare, используя Google Chrome в качестве браузера и wireshark в качестве анализатора пакетов. Я все еще могу прочитать имя сервера в виде простого текста в пакете приветствия клиента.

введите описание изображения здесь

Итак, остерегайтесь того, что вы можете прочитать, потому что это все еще не анонимное соединение. Промежуточное программное обеспечение между клиентом и сервером может регистрировать каждый домен, запрошенный клиентом.

Таким образом, похоже, что шифрование SNI требует дополнительных реализаций для работы вместе с TLSv1.3

В следующей статье описывается шифрование SNI, предоставляемого Cloudflare как часть TLSv1.3. Однако все URL-адреса HTTP из cloudflare.com находятся в виде простого текста в пакете TCP в TLS v1.3.

[ https://blog.cloudflare.com/encrypted-sni/][3]


«SNI может быть зашифрован» - это ключевой момент. Проверка cloudflare.com/ssl/encrypted-sni с текущим Google Chrome говорит: «Ваш браузер не зашифровывал SNI при посещении этой страницы». Для танго
нужны

Очевидно, что текущий Firefox может выполнять ESNI, но по умолчанию он отключен: вам нужно включить его network.security.esni.enabled, установить network.trr.modeзначение 2 (которое в настоящее время устанавливает для вашего распознавателя DoH значение CloudFlare) и перезапустить браузер (sic!); тогда он будет использовать ESNI - если он поддерживается инфраструктурой домена. См. Blog.mozilla.org/security/2018/10/18/… для получения подробной информации.
Писквор покинул здание

2

Хотя здесь уже есть несколько хороших ответов, большинство из них сосредоточены на браузерной навигации. Я пишу это в 2018 году, и, возможно, кто-то хочет знать о безопасности мобильных приложений.

Для мобильных приложений , если вы контролируете оба конца приложения (сервер и приложение), пока вы используете HTTPS, вы защищены . iOS или Android проверит сертификат и уменьшит возможные атаки MiM (это было бы единственным слабым местом во всем этом). Через HTTPS-соединения вы можете отправлять конфиденциальные данные, которые будут зашифрованы во время транспортировки . Просто ваше приложение и сервер будут знать любые параметры, отправленные через https.

Единственное «возможно» здесь было бы, если клиент или сервер заражены вредоносным программным обеспечением, которое может видеть данные, прежде чем они будут упакованы в https. Но если кто-то заражен этим программным обеспечением, у него будет доступ к данным, независимо от того, что вы используете для их транспортировки.


1

Кроме того, если вы создаете ReSTful API, утечки в браузере и проблемы с реферером http в основном сводятся к минимуму, поскольку клиент может не являться браузером и у вас может не быть людей, нажимающих на ссылки.

Если это так, я бы рекомендовал oAuth2 войти в систему, чтобы получить токен на предъявителя. В этом случае единственными конфиденциальными данными будут исходные учетные данные ... которые, вероятно, должны быть в любом случае после запроса.


0

Хотя у вас уже есть очень хорошие ответы, мне очень нравится объяснение на этом сайте: https://https.cio.gov/faq/#what-information-does-https-protect

короче говоря: использование HTTPS скрывает:

  • HTTP метод
  • параметры запроса
  • POST тело (если есть)
  • Заголовки запроса (куки включены)
  • Код состояния
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.