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