Все ли шифрованные URL-адреса при использовании шифрования TLS/SSL (HTTPS)? Я хотел бы знать, потому что я хочу, чтобы все данные URL были скрыты при использовании TLS/SSL (HTTPS).
Если TLS/SSL дает вам полное шифрование URL-адресов, мне не нужно беспокоиться о том, чтобы скрывать конфиденциальную информацию из URL-адресов.
Да, соединение SSL находится между уровнем TCP и уровнем HTTP. Клиент и сервер сначала устанавливают защищенное зашифрованное TCP-соединение (через протокол SSL/TLS), а затем клиент отправляет HTTP-запрос (GET, POST, DELETE...) по этому зашифрованному TCP-соединению.
Так как никто не обеспечил захват провода, здесь один.
Имя сервера (доменная часть URL-адреса) представлено в пакете ClientHello в виде простого текста.
Ниже показан запрос браузера: https://i.stack.imgur.com/path/?some=parameters&go=here
См. Этот ответ для получения дополнительной информации о полях версий 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.1 HTTP-запросе, ПОСЛЕ того, как будет установлен безопасный канал TLS.
Доменное имя МОЖЕТ быть передано в открытом виде (если расширение SNI используется в рукопожатии TLS), но URL (путь и параметры) всегда шифруются.
Спасибо carlin.scott за то, что поднял этот вопрос.
Полезная нагрузка в расширении SNI теперь может быть зашифрована с помощью этого проекта предложения RFC. Эта возможность существует только в TLS 1.3 (в качестве опции и до двух сторон для ее реализации), и нет обратной совместимости с TLS 1.2 и ниже.
CloudFlare делает это, и вы можете прочитать больше о внутренностях здесь - Если курица должна быть раньше яйца, куда вы положите курицу?
На практике это означает, что вместо передачи полного доменного имени в виде простого текста (как показано в захвате Wireshark) теперь оно шифруется.
ПРИМЕЧАНИЕ. Это касается аспекта конфиденциальности в большей степени, чем аспект безопасности, поскольку обратный поиск DNS МОЖЕТ в любом случае выявить целевой узел назначения.
Как уже указывали другие ответы, https "URL" действительно шифруются. Тем не менее, ваш DNS-запрос/ответ при разрешении имени домена, вероятно, нет, и, конечно, если вы используете браузер, ваши URL-адреса также могут быть записаны.
Весь запрос и ответ зашифровываются, включая URL.
Обратите внимание, что при использовании прокси-сервера HTTP он знает адрес (домен) целевого сервера, но не знает запрошенный путь на этом сервере (т.е. запрос и ответ всегда зашифрованы).
Я согласен с предыдущими ответами:
Чтобы быть явным:
С TLS первая часть URL-адреса (https://www.example.com/) по-прежнему отображается, когда она создает соединение. Вторая часть (/herearemygetparameters/1/2/3/4) защищена TLS.
Однако существует ряд причин, по которым вы не должны указывать параметры в запросе GET.
Во-первых, как уже упоминалось другими: - утечка через адресную строку браузера - утечка через историю
В дополнение к этому у вас есть утечка URL-адреса через HTTP-референт: пользователь видит сайт A в TLS, затем нажимает ссылку на сайт B. Если оба сайта находятся на TLS, запрос на сайт B будет содержать полный URL-адрес от сайт A в параметре referer запроса. А администратор с сайта B может извлечь его из файлов журнала сервера B.)
В дополнение к полезному ответу Марка Новаковского - URL-адрес хранится в журналах на сервере (например, в /etc/httpd/logs/ssl _access_log), поэтому, если вы не хотите, чтобы сервер сохранял информацию в долгосрочной перспективе, не помещайте его в URL-адрес.
И да и нет.
Это может измениться в будущем с зашифрованными SNI и DNS, но с 2018 года обе технологии обычно не используются.
Примечание для запросов GET пользователь по-прежнему сможет вырезать и вставлять URL-адрес из адресной строки, и вы, вероятно, не захотите помещать туда конфиденциальную информацию, которую может увидеть любой, кто смотрит на экран.
Сторонняя группа, которая отслеживает трафик, также может определить посещаемую страницу, исследуя ваш трафик, сравнивая ее с трафиком, который другой пользователь имеет при посещении сайта. Например, если на сайте было всего 2 страницы, одна намного больше, чем другая, то сравнение размера передачи данных сообщит, какую страницу вы посетили. Есть способы, которыми это может быть скрыто от сторонних разработчиков, но они не являются обычным режимом работы с сервером или браузером. См., Например, эту статью от SciRate, https://scirate.com/arxiv/1403.0297.
В целом, другие ответы правильны, хотя в этой статье показано, что посещаемые страницы (например, URL) могут быть определены достаточно эффективно.
Ссылка на мой ответ на повторяющийся вопрос. URL-адрес доступен не только в истории браузеров, но и в качестве заголовка HTTP Referer, который, если вы используете стороннее содержимое, предоставляет URL-адрес источникам вне вашего контроля.
Вы не всегда можете рассчитывать на конфиденциальность полного URL-адреса. Например, как это иногда бывает в корпоративных сетях, поставляемые устройства, такие как ПК вашей компании, настроены с дополнительным "доверенным" корневым сертификатом, чтобы ваш браузер мог спокойно доверять проверке трафика (https) прокси (человек в середине), Это означает, что полный URL-адрес выставлен для проверки. Обычно это сохраняется в журнале.
Кроме того, ваши пароли также отображаются и, вероятно, регистрируются, и это еще одна причина использовать одноразовые пароли или часто менять свои пароли.
Наконец, содержимое запроса и ответа также отображается, если иное не зашифровано.
Один пример настройки инспекции описан Checkpoint здесь. Также можно настроить старое "интернет-кафе" с использованием поставляемого ПК.
Хотя здесь уже есть несколько хороших ответов, большинство из них сосредоточены на браузерной навигации. Я пишу это в 2018 году, и, возможно, кто-то хочет знать о безопасности мобильных приложений.
Для мобильных приложений, если вы контролируете оба конца приложения (сервер и приложение), если вы используете HTTPS, вы защищены. iOS или Android проверит сертификат и уменьшит возможные атаки MiM (это будет единственным слабым местом во всем этом). Через HTTPS-соединения вы можете отправлять конфиденциальные данные, которые будут зашифрованы во время транспортировки. Просто ваше приложение и сервер будут знать любые параметры, отправленные через https.
Единственное "возможно" здесь было бы, если клиент или сервер заражены вредоносным программным обеспечением, которое может видеть данные, прежде чем они будут упакованы в https. Но если кто-то заражен таким программным обеспечением, у него будет доступ к данным, независимо от того, что вы используете для их транспортировки.
Кроме того, если вы создаете ReSTful API, проблемы утечки в браузере и реферера http в основном сводятся к минимуму, поскольку клиент может не являться браузером и у вас может не быть людей, нажимающих на ссылки.
Если это так, я бы рекомендовал oAuth2 войти, чтобы получить токен на предъявителя. В этом случае единственными конфиденциальными данными будут исходные учетные данные... которые, вероятно, должны быть в любом случае после запроса.
Сейчас 2019 год, и TLS v1.3 был выпущен. Согласно cloudflare, SNI может быть зашифрован благодаря TLS v1.3. Итак, я сказал себе здорово! давайте посмотрим, как это выглядит в TCP-пакетах cloudflare.com Итак, я поймал пакет рукопожатия "hello client" из ответа сервера cloudflare. Я все еще могу прочитать имя сервера в виде обычного текста.
Итак, остерегайтесь того, что вы можете прочитать, потому что это все еще не анонимное соединение, поскольку посредник может видеть имя целевого сервера.
Таким образом, похоже, что шифрование SNI требует дополнительных реализаций для работы вместе с TLSv1.3
В следующей статье описывается шифрование SNI, предоставляемого Cloudflare как часть TLSv1.3. Однако все URL-адреса HTTP от cloudlfare.com можно прочитать в виде простого текста в пакете TCP в TLS v1.3.
Я думаю, что вы должны пройти следующую документацию.
Эта документация объяснила ключевые понятия очень хорошо. Это будет отличная помощь.
Пока вы не установили соединение с сервером, кстати, GET используется только для 'name', что вы получите (не для отправки данных), вы должны использовать POST для отправки данных.