Да, и здесь они не нуждаются в магии, только в простом сопоставлении содержимого пакета TCP. Несмотря на то, что SSH и TLS (SSL) шифруют свои полезные данные, сами заголовки протокола по-прежнему различимы и сильно отличаются друг от друга. Например, соединение SSHv2 всегда начинается с того, что клиент отправляет SSH-2.0-(client name and version) . Точно так же, даже если ваш брандмауэр не может действительно знать, несет ли соединение TLS HTTP внутри, он может распознавать сам TLS .
Такая проверка уровней над TCP обычно относится к "Deep Packet Inspection", относительно распространенной функции.
Один очевидный способ обойти это - туннелировать SSH внутри TLS - например, используя stunnel, haproxy или sniproxy. (В дополнение к обычному туннелированию, где порт 443 выделен для SSH-over-TLS, они также могут мультиплексировать SSH / HTTP / другие протоколы через один и тот же порт на основе SNI и ALPN.)
Хотя это не всегда будет препятствовать действительно сложному анализу трафика, оно все равно будет игнорировать большинство фильтров, которые просто проверяют, "выглядит ли это как заголовок TLS".
И еще есть надоедливые межсетевые экраны - те, которые перехватывают TLS для расшифровки и повторного шифрования всего трафика. Они действительно могут видеть внутри TLS и могут передавать HTTP-запросы, блокируя все остальное. (Обратите внимание, что некоторые антивирусные программы также делают то же самое.) Вы можете распознать этот вид, посмотрев на сертификаты сервера; все сгенерированные прокси сертификаты выглядят одинаково и часто не проходят проверку, в то время как реальные сертификаты выдаются различными ЦС.
