Существуют брандмауэры, которые анализируют проходящий трафик и блокируют его, если он нежелателен. Насколько хорошо эти брандмауэры работают с зашифрованным трафиком, например, HTTPS или IMAP через SSL?
Пример: может ли брандмауэр различать HTTPS-трафик на порту 443 и, скажем, защищенный трафик удаленного рабочего стола через порт 443?
решение1
В вашем конкретном примере да, это возможно.
HTTPS запускает сеанс TLS с удаленным устройством.
TLSv1 Client Hello
Secure RDP запускает сеанс RDP, который устанавливает защищенное соединение TLS между двумя концами сеанса.
X.224 Connection Request (0xe0)
Поскольку протоколы запуска сеанса различны, межсетевой экран с отслеживанием состояния должен уметь отличать запуск HTTPS-соединения от чего-либо другого.
В общем случае брандмауэр не сможет обнаружить что-то вроде SSH-over-HTTPS, поскольку трафик SSH скрыт внутри трафика HTTPS. Единственный способ, которым он может это обнаружить, — это эвристический анализ шаблонов трафика, но я не знаю ничего, что делает это.
Для IMAP есть два режима защиты. Один — через SSL, другой — через TLS. Метод SSL выглядит так же, как соединение HTTPS, только на другом порту, и если удаленный порт тот же, то он мало что может с этим поделать. TLS, с другой стороны, согласовывается между обоими концами разговора, поэтому запуск сеанса заметно отличается и легко обнаруживается.
Главное, что нужно помнить, это то, что SSL создает TCP-оболочку, через которую проходит трафик. Многие протоколы включают метод согласованной безопасности внутри самого протокола, который использует во многом те же технологии, что и оболочка, но использует другой метод запуска сеанса, что делает его дифференцируемым.
решение2
Некоторые продукты брандмауэров/прокси-серверов могут выполнять «авторизованную атаку типа «человек посередине»» на соединения TLS; например, Squid называет эту функцию «SSL-поднятие”. Прокси-сервер, который делает это, будет иметь полный доступ к данным открытого текста, передаваемым внутри сеанса TLS. Однако клиент за таким прокси-сервером получит другой сертификат сервера (предоставленный самим прокси-сервером вместо реального сервера), что вызовет ошибки или предупреждения TLS, если только клиент не настроен на ожидание таких сертификатов (путем добавления сертификата прокси-центра в список доверенных корневых сертификатов).