Зашифрованы ли URL-адреса HTTPS?
https://stackoverflow.com/questions/499591
-
20-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Все ли 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] не предоставляет клиенту механизма для сообщения серверу имя сервера, с которым он связывается. Может быть желательно, чтобы клиенты предоставляли эту информацию для облегчения безопасных подключений к серверам, на которых размещено несколько "виртуальных" серверов по одному базовому сетевому адресу.
Чтобы указать имя сервера, клиенты МОГУТ включать расширение типа "имя_сервера" в (расширенном) клиентском приветствии.
Короче говоря:
ПОЛНОЕ доменное имя (доменная часть URL-адреса) мочь быть переданным в ясном внутри
ClientHelloпакет, если используется расширение SNIОстальная часть URL-адреса (
/path/?some=parameters&go=here) не имеет права находиться внутриClientHelloпоскольку URL-адрес запроса является HTTP-адресом (уровень OSI 7), следовательно, он никогда не будет отображаться при TLS-квитировании (уровень 4 или 5).Это произойдет позже, вGET /path/?some=parameters&go=here HTTP/1.1HTTP - запрос, ПОСЛЕ в безопасный Установлен канал TLS.
КРАТКОЕ ИЗЛОЖЕНИЕ
Доменное имя МОЖЕТ передаваться в открытом виде (если при TLS-квитировании используется расширение SNI), но URL-адрес (путь и параметры) всегда зашифрован.
ОБНОВЛЕНИЕ ЗА МАРТ 2019 ГОДА
Спасибо карлин.Скотт за то, что затронул эту тему.
Полезная нагрузка в расширении SNI теперь может быть зашифрована с помощью этот проект предложения RFC.Эта возможность существует только в TLS 1.3 (как опция, и реализовать ее должны оба конца), и обратной совместимости с TLS 1.2 и ниже нет.
CloudFlare делает это, и вы можете прочитать больше о внутренних компонентах здесь — Если курица должна быть приготовлена раньше яйца, куда вы кладете курицу?
На практике это означает, что вместо передачи полного доменного имени в виде обычного текста (как показано на записи Wireshark), теперь оно зашифровано.
ПРИМЕЧАНИЕ: Это больше касается аспекта конфиденциальности, чем безопасности, поскольку обратный поиск в DNS в любом случае МОЖЕТ выявить предполагаемый конечный хост.
Весь запрос и ответ зашифрованы, включая URL.
Обратите внимание, что когда вы используете HTTP-прокси, он знает адрес (домен) целевого сервера, но не знает запрошенный путь на этом сервере (т.е.запрос и ответ всегда зашифрованы).
Я согласен с предыдущими ответами:
Быть явным:
С TLS первая часть URL-адреса (https://www.example.com/) все еще виден по мере построения соединения.Вторая часть (/herearemygetparameters/1/2/3/4) защищена протоколом TLS.
Однако существует ряд причин, по которым вам не следует указывать параметры в запросе GET.
Во-первых, как уже упоминалось другими:- утечка через адресную строку браузера - утечка через историю
В дополнение к этому у вас есть утечка URL-адреса через http refererer:пользователь видит сайт 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 Refererer, который, если вы используете сторонний контент, предоставляет URL-адрес источникам, находящимся вне вашего контроля.
Вы также не всегда можете рассчитывать на конфиденциальность полного URL-адреса.Например, как это иногда бывает в корпоративных сетях, поставляемые устройства, такие как ваш корпоративный компьютер, настроены с дополнительным "доверенным" корневым сертификатом, чтобы ваш браузер мог спокойно доверять проверке https-трафика прокси-сервером (man-in-the-middle).Это означает, что полный URL-адрес доступен для проверки.Обычно это сохраняется в журнале.
Кроме того, ваши пароли также доступны и, вероятно, регистрируются, и это еще одна причина использовать одноразовые пароли или часто менять свои пароли.
Наконец, содержимое запроса и ответа также предоставляется, если оно не зашифровано иным образом.
Один из примеров настройки проверки описан Контрольно - пропускной пункт здесь.Таким же образом можно настроить "интернет-кафе" в старом стиле с использованием прилагаемых ПК.
Сейчас 2019 год, и выпущен TLS версии v1.3.Согласно Cloudflare, SNI может быть зашифрован благодаря TLS версии v1.3.Итак, я сказал себе: отлично!давайте посмотрим, как это выглядит в TCP-пакетах cloudflare.com Итак, я перехватил пакет рукопожатия "клиент привет" из ответа сервера cloudflare, используя Google Chrome в качестве браузера и wireshark в качестве анализатора пакетов.Я все еще могу прочитать имя сервера в виде обычного текста в пакете приветствия клиента.
Итак, остерегайтесь того, что вы можете прочитать, потому что это все еще не анонимное соединение, поскольку посредник может видеть имя целевого сервера.
Таким образом, похоже, что шифрование SNI требует дополнительных реализаций для работы вместе с TLSv1.3
В следующей статье описывается шифрование SNI, предоставляемое Cloudflare как часть TLSv1.3.Однако все URL-адреса HTTPs из cloudflare.com представлены в виде обычного текста внутри TCP-пакета в версии TLS v1.3
Хотя здесь уже есть несколько хороших ответов, большинство из них сосредоточены на навигации по браузеру.Я пишу это в 2018 году, и, вероятно, кто-то хочет узнать о безопасности мобильных приложений.
Для мобильных приложений, если вы контролируете оба конца приложения (сервер и приложение), при условии, что вы используете HTTPS ты в безопасности.iOS или Android проверят сертификат и смягчат возможные MiM-атаки (это было бы единственным слабым местом во всем этом).Вы можете отправлять конфиденциальные данные через HTTPS-соединения, которые будут зашифрованы во время транспортировки.Только ваше приложение и сервер будут знать все параметры, отправленные через https.
Единственное "возможно" здесь было бы, если бы клиент или сервер были заражены вредоносным программным обеспечением, которое может видеть данные до того, как они будут завернуты в https.Но если кто-то заражен такого рода программным обеспечением, у него будет доступ к данным, независимо от того, что вы используете для их транспортировки.
Кроме того, если вы создаете RESTful API, проблемы с утечкой браузера и http-ссылками в основном устраняются, поскольку клиент может не быть браузером, и у вас могут не быть пользователей, переходящих по ссылкам.
Если это так, я бы рекомендовал войти в систему OAuth2, чтобы получить токен на предъявителя.В этом случае единственными конфиденциальными данными будут исходные учетные данные...которые, вероятно, в любом случае должны быть в запросе post
