Комментарий «Нет прямых прокси HTTPS» не соответствует действительности. Они очень распространены. Любая компания приличного размера будет включать в себя явные прямые прокси-серверы для SSL, чтобы они могли расшифровывать трафик https для целей мониторинга, ведения журналов и фильтрации - распространенным эвфемизмом является «Отчетность о соответствии».
Некоторый фон, который вы, возможно, уже знаете, для контекста:
Начальное рукопожатие сеанса HTTPS состоит из трех частей:
Приветствие: сообщение «ClientHello», содержащее поддерживаемые им версии и шифры SSL, и сообщение «ServerHello» с аналогичной информацией. Этот шаг и следующий не зашифрованы.
Сертификат Exchange: Сервер предоставляет свой сертификат SSL, который клиент должен решить, доверяет ли он ему, - обычно реализуется с неявным доверием для тех, кто подписан центрами сертификации и требует вмешательства пользователя для самостоятельной подписи.
- Обмен ключами - используется метод, определенный на шаге 1; самый простой метод - транзакция типа обмена ключами RSA: клиент генерирует ключ, используя случайное число, и шифрует его, используя открытый ключ сервера. Это расшифровывается с помощью закрытого ключа сервера (его можно зашифровать только с помощью открытого ключа, его нельзя расшифровать без закрытого ключа, что является тонким, но многим не понятным).
С этого момента происходит полностью зашифрованная связь с почти всем зашифрованным пакетом TCP / IP (за исключением заголовков / полей, необходимых для маршрутизации)
Ответ на ваши вопросы заключается в том, что прямой прокси-сервер требует, чтобы прокси-сервер полностью расшифровывал связь HTTPS. Клиент никогда не связывается напрямую с намеченным сервером (иногда даже не зная, что это не так, о чем я расскажу ниже).
Вот объяснение от Palo Alto Networks о том, как работает прямой https-прокси (PAN-OS ссылается на их сетевое ПО):
- Клиент пытается связаться с www.google.com с помощью https. Трафик соответствует политике дешифрования.
- Этот трафик обрабатывается нашим прокси-сервером SSL, а сертификат для www.google.com создается нашей внутренней PKI (подписанной сертификатом CA).
- PAN-OS проксирует трафик ssl и устанавливает новое соединение ssl с веб-сервером.
- Веб-сервер начинает рукопожатие с устройством PAN-OS.
- Устройство PAN-OS завершает свое рукопожатие SSL с клиентом, представляющим сгенерированный сертификат в сообщении приветствия сервера.
Это (если злонамеренный) явный человек в середине атаки - он превращает двухстороннюю транзакцию: ПК <====> google - в две отдельные транзакции: ПК <====> Прокси и Прокси <==== > Гугл.
Примечание:
Поскольку прямые прокси-серверы в основном используются для мониторинга трафика ssl, интересно, что не прокси-метод также обсуждался в этой ссылке PAN - входящая «проверка / дешифрование», которая требует, чтобы брандмауэр имел сертификаты и ключи серверов, и поэтому может полностью расшифровать связь с помощью простого мониторинга пакетов. Кроме того, это немного расстраивает, что они рекламируют это как ключевую функцию, когда можно надеяться, что у него будет очень мало вариантов использования - это требует, чтобы у оператора брандмауэра были открытые и закрытые ключи стороннего сайта - например, Google's закрытые ключи Казалось бы, это не будет распространенным явлением.
Существует много разных способов реализации прямых прокси, и я едва касаюсь их - многие, если не большинство прямых прокси, реализованы как «прозрачные» прямые прокси, то есть клиенты вообще не настроены на подключение к прокси, а межсетевой экран / прокси вставляет себя в транзакцию. Прямой прокси, описанный выше, является «прозрачным» прокси. Как только клиент принял сертификат от прокси-сервера, который, если он является сертификатом, подписанным ЦС, обычно является автоматическим, клиентские машины будут получать пакеты, которые прокси-сервер изменил, чтобы они выглядели как исходные (например, Google).
Обновление, чтобы получить информацию из комментариев:
Другой способ реализации прямого прокси-сервера использует туннелирование TCP, которое эффективно создает оболочку для зашифрованных данных. Начальные транзакции здесь не зашифрованы и инициируются клиентом с помощью запроса CONNECT к прокси-серверу. Как только соединение установлено, связь между клиентом и сервером зашифрована. Смотрите это для деталей.
HSTS (HTTP Strict Transport Security) - это протокол, разработанный для предотвращения перехвата злоумышленниками запросов от серверов для перевода текущей транзакции из http в https. Теория, лежащая в основе этого, состоит в том, что внедрить человека в середине атаки на http тривиально, и этот прокси-агент может затем подделать переход к https, если он увидит запрос на переход. Это напрямую не влияет на работу прокси-серверов https, но связано с ними; вот гораздо лучшее объяснение
MITM-атаки, HTTPS и прокси-серверы. Вот отличное объяснение того, почему атаки MITM с использованием прокси-серверов в настоящее время не эффективны при использовании «прямого» HTTPS (то есть не перехода HTTP к HTTPS, который частично адресован HSTS). Вот дополнительная информация о MITM-атаках и HTTPS из вопроса о crypto.stackexchange.
Я думаю, что отвечает на оригинальные и обновленные вопросы. Если у меня что-то не так или неясно, дайте мне знать, и я обновлю.
