Evet, ve burada herhangi bir sihre ihtiyaçları yok, sadece TCP paketinin içeriği ile önemsiz eşleşmeleri gerekiyor. SSH ve TLS (SSL) kendi şifrelemek olsa yükleri , protokol başlıklarını kendileri hala ayırt ve birbirinden çok farklıdır. Örneğin, bir SSHv2 bağlantısı daima müşteri gönderimiyle başlar SSH-2.0-(client name and version). Benzer şekilde, güvenlik duvarınız TLS bağlantısının içinde HTTP olup olmadığını gerçekten bilemese de, TLS'nin kendisini tanıyabilir .
TCP'nin üzerindeki katmanların bu şekilde denetlenmesi genellikle nispeten yaygın bir özellik olan "Derin Paket Denetimi" altına girer.
Bunu atlamanın açık bir yolu, SSH'yi TLS içinde tünellemektir - örneğin, sersemletici, haproxy veya sniproxy. (443 numaralı bağlantı noktasının TLS üzerinden SSH'ye tahsis edildiği düz tünele ek olarak, SNI ve ALPN'i temel alarak aynı bağlantı noktası üzerinden SSH / HTTP / diğer protokolleri çoğaltabilirler.)
Bu her zaman gerçekten karmaşık trafik analizini yenmeyecek olsa da, sadece "bu bir TLS başlığı gibi görünüyor" u kontrol eden filtrelerin çoğunu atlayacaktır.
Ve sonra can sıkıcı bir güvenlik duvarı var - TLS'yi tüm trafiğin şifresini çözmek ve yeniden şifrelemek için engelleyenler . Bunlar aslında TLS'nin içini görebilir ve diğer her şeyi engellerken HTTP isteklerini iletebilir. (Bazı virüsten koruma programlarının da aynı şeyi yaptığına dikkat edin.) Bu tür bilgileri sunucu sertifikalarına bakarak tanıyabilirsiniz; Proxy tarafından üretilen tüm sertifikalar aynı görünür ve gerçek sertifikalar çeşitli CA'lar tarafından verilirken çoğu zaman onaylamayı geçemez.