Ошибка TLS через прокси: туннель, имя сервера и цепочка доверия
Ошибка TLS требует сначала определить фактический маршрут. Обычный HTTP-прокси использует CONNECT для HTTPS, SOCKS5 создаёт реле собственным запросом, а HTTPS-прокси добавляет отдельный TLS-участок до самого прокси. Только после этого проверяют имя сервера, время, доверенную цепочку и наличие утверждённой корпоративной инспекции.
Главное за минуту
- Успешный CONNECT или ответ SOCKS5 подтверждает только соответствующий этап, но не проверку сертификата и не ответ приложения.
- При TLS-инспекции клиент соединяется с корпоративным посредником, который создаёт отдельное TLS-соединение к назначению.
- HTTP CONNECT и запрос соединения SOCKS5 — разные этапы разных протоколов.
- При инспекции проверяют два TLS-соединения и две стороны доверия.
Определите вид прокси
Зафиксируйте, используется ли обычный HTTP-прокси, HTTPS-прокси или SOCKS5. Для HTTPS через HTTP-прокси ожидается CONNECT; SOCKS5 использует собственный запрос соединения и не возвращает HTTP 200 CONNECT. У HTTPS-прокси сначала проверяется отдельный сертификат адреса подключения к прокси.
Для каждого вида пути храните отдельный ожидаемый результат: TLS до HTTPS-прокси, ответ CONNECT у HTTP-прокси либо ответ на запрос соединения SOCKS5. Ошибка на одном этапе не исправляется сменой сертификата другого этапа или повторной сменой оборудования.
Отделите туннель или реле от TLS
Успешный CONNECT означает, что HTTP-прокси согласился установить туннель для указанного назначения; успешный ответ SOCKS5 относится к его запросу соединения. Ни один из этих результатов не подтверждает успешное TLS-согласование, имя сертификата или корректный HTTP-ответ внутри соединения.
После установления туннеля или реле проверьте точное имя назначения, системное время, срок сертификата и доверенную цепочку. Отрицательные проверки с неподходящим именем или тестовым недоверенным сертификатом выполняйте только в собственной лаборатории. Не включайте глобальное игнорирование ошибок сертификата ради одного теста.
Проверьте имя, время и инспекцию
Без инспекции клиент проверяет сертификат целевого сервера внутри туннеля или реле. При утверждённой TLS-инспекции корпоративный посредник завершает TLS-соединение клиента, предъявляет управляемый сертификат и создаёт отдельное TLS-соединение к назначению. Эти две проверки и их журналы нельзя смешивать.
Для утверждённой инспекции ведите реестр доверенных центров, владельцев, охваченных систем и срока действия. Отдельно проверяйте сертификат, предъявленный клиенту, и результат TLS-соединения посредника с назначением. После удаления корпоративного корневого сертификата тестовое устройство не должно продолжать доверять прежней цепочке.
Соберите безопасные доказательства
Сохраните вид прокси, результат соединения с посредником, результат CONNECT или SOCKS5, имя назначения, системное время, версию TLS и класс ошибки сертификата. Не записывайте содержимое, cookies, токены, секреты сессии и заголовки авторизации.
Полезны доля успешных TLS-согласований, ошибки имени и цепочки, версия протокола и длительность этапа. Не записывайте ключевой материал TLS, данные возобновления сессии или заголовки авторизации. Оповещение создавайте по устойчивому росту конкретного класса ошибок, чтобы один неверно настроенный клиент не выглядел массовым сбоем.
Практический чек-лист
- 1Определите HTTP, HTTPS-прокси или SOCKS5.
- 2Разделите соединение с прокси, туннель или реле и TLS.
- 3Не отключайте проверку имени и цепочки доверия.
- 4Разделите метрики соединения с прокси, туннеля или реле и TLS.
- 5Проверьте удаление корпоративного корневого сертификата.
Источники и документы
Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.