그렇습니다. 여기에는 TCP 패킷 내용에 대한 간단한 일치만으로 마술이 필요하지 않습니다. SSH와 TLS (SSL)가 페이로드를 암호화하더라도 프로토콜 헤더 자체 는 여전히 구별 가능하고 서로 매우 다릅니다. 예를 들어 SSHv2 연결은 항상 클라이언트 전송으로 시작합니다 SSH-2.0-(client name and version)
. 마찬가지로 방화벽 에서 TLS 연결이 HTTP를 내부에 전달하는지 여부를 실제로 알 수는 없지만 TLS 자체를 인식 할 수 있습니다 .
TCP 이상의 계층 검사는 일반적으로 비교적 일반적인 기능인 "딥 패킷 검사"에 속합니다.
이를 우회하는 확실한 방법 중 하나는 stunnel, haproxy 또는 sniproxy 등을 사용하여 TLS 내부에서 SSH를 터널링하는 것입니다. 포트 443이 SSH-over-TLS 전용 인 일반 터널링 외에도 SNI 및 ALPN을 기반으로 동일한 포트에서 SSH / HTTP / 기타 프로토콜을 멀티플렉싱 할 수 있습니다.
이것이 항상 정교한 트래픽 분석을이기는 것은 아니지만 여전히 "TLS 헤더처럼 보이는지"확인하는 대부분의 필터를 우회합니다.
그리고 성가신 종류의 방화벽이 있습니다. 방화벽은 TLS 를 가로 채서 모든 트래픽을 해독하고 다시 암호화합니다. 이들은 실제로 TLS 내부를 볼 수 있으며 다른 모든 것을 차단하면서 HTTP 요청을 전달할 수 있습니다. (일부 바이러스 백신 프로그램도 같은 작업을 수행합니다.) 서버 인증서를 보면 이러한 종류를 인식 할 수 있습니다. 모든 프록시 생성 인증서는 동일하게 보이며 종종 유효성 검사를 통과하지 못하는 반면 실제 인증서는 다양한 CA에서 발급됩니다.