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

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

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

вопрос задан 31.01.2009
Daniel Kivatinos
8290 репутация

12 ответов


  • 735 рейтинг

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

    ответ дан Marc Novakowski, с репутацией 36801, 31.01.2009
  • 309 рейтинг

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

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

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

    От https: // www. IETF. орг / гк / rfc3546. TXT :

    3. 1. Указание имени сервера

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

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


    Короче:

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

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


    РЕЗЮМЕ

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

    ответ дан evilSnobu, с репутацией 10640, 2.08.2016
  • 139 рейтинг

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

    ответ дан Zach Scrivena, с репутацией 23869, 31.01.2009
  • 95 рейтинг

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

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

    ответ дан Peter Štibraný, с репутацией 26618, 31.01.2009
  • 85 рейтинг

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

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

    С TLS, первая часть URL ( https: // www. пример. com / ) все еще виден, поскольку это строит соединение. Вторая часть (/ herearemygetparameters / 1/2/3/4) защищена TLS.

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

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

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

    ответ дан Tobias, с репутацией 867, 28.07.2013
  • 45 рейтинг

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

    ответ дан Rhodri Cusack, с репутацией 559, 2.11.2010
  • 18 рейтинг

    Да и нет.

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

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

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

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

    ответ дан SoapBox, с репутацией 17667, 31.01.2009
  • 7 рейтинг

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

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

    ответ дан pbhj, с репутацией 181, 14.08.2015
  • 3 рейтинг

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

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

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

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

    ответ дан Don Gillis, с репутацией 71, 17.11.2016
  • 3 рейтинг

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

    ответ дан JoshBerke, с репутацией 52960, 15.04.2016
  • 1 рейтинг

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

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

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

    ответ дан Ricardo BRGWeb, с репутацией 500, 3.08.2018
  • 0 рейтинг

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

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

    ответ дан Chris Rutledge, с репутацией 136, 22.08.2018