nodejs - typescript http request




Зашифрованы ли URL HTTPS? (8)

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

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

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

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


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

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

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

Один пример настройки проверки описан здесь Checkpoint . Также можно настроить старое «интернет-кафе» с использованием поставляемых ПК.


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


И да и нет.

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

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

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

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


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

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


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

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

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

Из https://www.ietf.org/rfc/rfc3546.txt :

3.1. Индикация имени сервера

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

Чтобы предоставить имя сервера, клиенты МОГУТ включать расширение типа «имя_сервера» в приветствии (расширенного) клиента.


Короче:

  • 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-запросе GET /path/?some=parameters&go=here HTTP/1.1 , ПОСЛЕ установления безопасного канала TLS.


УПРАВЛЯЮЩЕЕ РЕЗЮМЕ

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


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

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


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

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

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





httprequest