통과하는 트래픽을 분석하고 원하지 않는 경우 차단하는 방화벽이 있습니다. 이러한 방화벽은 암호화된 트래픽(예: HTTPS 또는 SSL을 통한 IMAP)에서 얼마나 잘 작동합니까?
예: 방화벽은 포트 443의 HTTPS 트래픽과 443을 통한 보안 원격 데스크톱 트래픽을 구별할 수 있습니까?
답변1
귀하의 구체적인 예에서는 가능합니다.
HTTPS는 원격지와 TLS 세션을 시작합니다.
TLSv1 Client Hello
보안 RDP는 세션의 두 끝 사이에서 TLS 보안 연결을 협상하는 RDP 세션을 시작합니다.
X.224 Connection Request (0xe0)
세션 시작 프로토콜이 다르기 때문에 상태 저장 방화벽은 HTTPS 연결 시작과 다른 연결을 구별할 수 있어야 합니다.
일반적인 경우 SSH 트래픽이 HTTPS 트래픽 내부에 숨겨져 있으므로 방화벽은 SSH-over-HTTPS와 같은 것을 감지할 수 없습니다. 이를 감지할 수 있는 유일한 방법은 트래픽 패턴에 대한 경험적 분석을 통해서이지만 그렇게 하는 방법은 없습니다.
IMAP의 경우 두 가지 보안 모드가 있습니다. 하나는 SSL을 통하고, 다른 하나는 TLS를 통합니다. SSL 방법은 단지 다른 포트에서의 HTTPS 연결처럼 보이며, 원격 포트가 동일하면 이에 대해 할 수 있는 일이 많지 않습니다. 반면 TLS는 대화의 양쪽 끝에서 협상되므로 세션 시작이 눈에 띄게 다르며 쉽게 감지됩니다.
명심해야 할 중요한 점은 SSL이 트래픽이 전달되는 TCP 래퍼를 생성한다는 것입니다. 많은 프로토콜에는 래퍼가 사용하는 것과 거의 동일한 기술을 활용하지만 차별화 가능한 다른 세션 시작 방법을 사용하는 프로토콜 자체 내부에 협상된 보안 방법이 포함되어 있습니다.
답변2
일부 방화벽/프록시 제품은 TLS 연결에 대해 "승인된 중간자 공격"을 수행할 수 있습니다. 예를 들어 Squid는 이 기능을 "SSL 범프". 이를 수행하는 프록시 서버는 TLS 세션 내에서 전송된 일반 텍스트 데이터에 대한 전체 액세스 권한을 갖습니다. 그러나 이러한 프록시 뒤에 있는 클라이언트는 다른 서버 인증서(실제 서버 대신 프록시 자체에서 제공)를 받게 되며, 클라이언트가 해당 인증서를 기대하도록 구성되지 않은 경우(프록시 CA 인증서를 추가하여) TLS 오류 또는 경고가 발생합니다. 신뢰할 수 있는 루트 인증서 목록).