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

Question

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

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

Answer 1

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

Answer 2

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

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

См. Этот ответ , чтобы узнать больше о полях версий TLS (их 3, а не версии, каждый из которых содержит номер версии!)

С https://www.ietf.org/rfc/rfc3546.txt:

3,1. Индикация имени сервера

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

Для предоставления имени сервера клиенты МОГУТ включать расширение типа "имя_сервера" в (расширенном) клиенте привет.

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

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

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

ИСПОЛНИТЕЛЬНОЕ РЕЗЮМЕ

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

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

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

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

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

Answer 6

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

Answer 7

Да и нет.

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

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

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

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

Answer 8

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

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

Answer 9

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

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

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

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

Answer 10

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