так как никто не обеспечил захват провода, вот один.
Имя Сервера (доменная часть 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 (уровень OSI 7), поэтому он никогда не будет отображаться в рукопожатии TLS (Уровень 4 или 5). Это придет позже в GET /path/?some=parameters&go=here HTTP/1.1 HTTP-запрос, после the безопасное установлен канал TLS.

РЕЗЮМЕ

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

Как другоеответы уже указывали, https " url " действительно зашифрованы. Однако ваш 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 страницы, одна намного больше другой, то сравнение размера передачи данных показало бы, какую страницу Вы посетили. Есть способы, которыми это может быть скрыто от третьей стороны, но они не являются нормальным поведением сервера или браузера. Посмотри например на этот бумага из Скирата,https://scirate.com/arxiv/1403.0297.

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

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

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

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

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

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

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

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

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

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

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