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

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

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

12 ответов


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


поскольку никто не предоставил захват провода, вот один.
Имя Сервера (доменная часть 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-адреса) мая быть передана в clear внутри 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.


РЕЗЮМЕ

доменное имя может быть передано в clear (если расширение SNI используется в рукопожатии TLS), но URL (путь и параметры) всегда зашифрован.


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


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

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


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

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

с 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.)


дополнение к полезному ответу от Марка Новаковского-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-адреса. Например, как это иногда бывает в корпоративных сетях, поставляемые устройства, такие как ПК вашей компании, настроены с дополнительным "доверенным" корневым сертификатом, чтобы ваш браузер мог спокойно доверять прокси-серверу (man-in-the-middle) проверка трафика https. Это означает, что полный URL-адрес предоставляется для проверки. Обычно это сохраняется в журнале.

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

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

один пример установки проверки описан контрольно-пропускной пункт здесь. Старый стиль "интернет-кафе" с использованием поставляемых ПК также может быть настроен таким образом.


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

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

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


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

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