태그: TLS

KCSC, Warning.or.kr에 적용된 필터링 방법과 사설

 

본래 방송통신심의위원회는 한국에서 ‘불법’으로 규정하는 사이트에 대한 접근을 차단하기 위하여 DPI 기반의 필터링을 도입합니다.
이 장비는 HTTP Request의 헤더를 분석하여 Host 필드의 값이 특정 도메인이라면 302 Redirect를 전송, warning.or.kr로 보내버립니다.

이 시스템은 2006년부터 동작하기 시작했는데, 이 시점에서 이미 기본권 침해 논란이 불거지기 시작하였습니다.
비록 Host 필드만을 확인하는 것이지만, 마음만 먹으면 특정 IP에서 어떠한 사이트에 들어갔는지 리스트를 작성할 수 있기 때문입니다.

사용자들은 이에 대응하여 DPI 장비가 필터링하지 못하도록 Host 필드의 뒤에 \n을 추가하거나, Host 대신 HoSt를 사용하는 등, HTTP 표준에는 부합하지만 DPI 장비의 필터에는 걸리지 않는 Request를 생성하여 우회하였습니다.

물론 KCSC가 DPI 장비를 개량하면서 다시 막혔습니다.

 

그러다 많은 사이트들이 HTTPS를 기본 지원하게 되면서, 기존의 HTTP 헤더 검사로는 차단이 불가능하게 되었습니다.
HTTPS 헤더를 까 봐야 암호화된 문자열들만이 나타나기 때문입니다.

그러자 KCSC는 DNS Spoofing을 시도합니다. 국내 ISP들의 DNS 서버에 특정 도메인 주소에 대한 응답을 warning.or.kr 서버로 돌리도록 한 것이죠.
물론 사용자들은 8.8.8.8과 1.1.1.1 등의 DNS 서버로 비교적 쉽게 우회할 수 있었고, 이에 한 때 1.1.1.1에 대한 접속을 차단하는 등의 강수를 두다가 철회하였습니다.

이 시점에서 KCSC가 취할 수 있는 대응 수단은 몇 가지가 있습니다.

 

1. DNS Request를 감시, 특정 도메인에 대한 요청을 찾으면 Request의 Source IP와 Response의 IP를 통해 TCP 커넥션을 식별, 차단
2. 특정 도메인에 대한 DNS 쿼리를 통해 IP Pool 확보, 해당 IP에 대한 접속을 차단
3. TLS의 Client Hello 메시지에서 암호화되지 않는 부분을 이용, Host 식별 후 차단
4. TLS의 Server Hello 메시지에서 Certificate를 확인, Server Name 필드를 식별 후 차단

 

1번은 기술적으로 구현이 힘들고 (컴퓨팅 파워 부족), DNS를 암호화하면 무력화됩니다
2번은 CloudFlare같은 접속 서비스를 사용하는 사이트에 대해서는 효과를 보기 힘든 데다(CloudFlare CDN 진입점을 차단할 수는 없으니), Virtual Host등을 이용하여 같은 서버를 사용할 경우 무고한 피해자가 발생할 수 있는 등의 문제가 있으며
3번은 현재 적용된 SNI 필터링입니다. 단, 이 문제점을 이미 인식하고 있기에 TLS 1.3에서 도입된 ESNI가 적용될 경우 무력화됩니다
4번은 ESNI가 보급된 이후에 적용될 것으로 예상되는 방법으로, 아직 대응방안이 마련되지 않았습니다

 

이 모든 것들을 한번에 해결할 수 있는 방법으로 VPN을 사용하는 것이 있으나, VPN 트래픽을 식별해낼 수 있으며, Packet을 Drop하는 방법으로 차단 또한 가능합니다.
이미 중국에서는 황금방패에 적용된 기법이고, VPN 트래픽 식별을 위해 머신러닝을 적용하고 있다는 이야기도 들려오고 있습니다.

결과적으로 창과 방패의 싸움이지만, 사법권력을 쥐고 있는 방패가 결국은 승리할 것으로 보입니다.

중국의 만리방화벽(Great Filrewall)과 VPN 서비스 차단 우회

최근 들어 중국의 인터넷 검열이 강화되고 있는 추세이다. 철저한 필터링 능력으로 유명한 만리방화벽(Great Firewall)이 이 역할을 수행한다.
만리방화벽은 중국 정부의 전면적인 인터넷 검열 시스템인 황금 방패 프로젝트(Golden Shield Project)의 일환으로, DPI 및 휴리스틱 분석을 통해 중국 정부에서 접속을 막은 사이트와 정보를 실시간으로 검열한다.

VPN은 이러한 만리방화벽을 우회하기 위한 수단으로 많이 사용되었는데, VPN에 대한 검열은 예전부터 계속되어 왔으나, 특히 2017년 9월부로 강화된 검열이 적용되고 있는 듯 하다. 기존에는 차단되지 않았던 중소규모 사업자들의 서비스도 차단되었으니 말이다.

 

VPN 연결을 테스트하면서 발견한 만리방화벽의 특징은 다음과 같다.

1. 시그니쳐 기반으로 차단을 수행한다
2. 연결을 차단하기 위하여 TCP RST를 전송, 세션을 끊어버린다
3. 일반적인 TLS 연결은 차단되지 않는다

 

나는 이 중에서 특히 1번에 주목하였는데, 이것은 만리방화벽의 한계를 드러내는 것이기 때문이다.
아무리 중국 정부가 많은 자원을 투입하여 패킷을 분석한다 한들, 대상이 인터넷 백본인 이상 검열 장비는 필연적으로 전체 패킷을 들여다볼 수 없다. 그러니 시그니쳐 분석을 통한 패턴 매칭으로 타겟 세션을 걸러내는 것이다.

다시 말해, VPN이 차단된 경우라도 사업자를 변경하거나, VPN 서버의 설정을 변경하는 등의 방법으로 시그니쳐를 뒤틀어놓으면 VPN 차단을 우회할 수 있다. 그리고 시그니쳐를 저장하고 매칭하는 시스템의 자원에도 한계가 있는 이상, 시그니쳐 데이터는 일정 기간동안 보존되어 사용되다가 만료될 것임을 쉽게 추론할 수 있다.

 

하지만 이러한 방법을 통한 우회는 결국 하나의 방편에 불과하다. VPN의 사용량이 많다면 시그니쳐는 빠르게 수집, 업데이트 될 것이고, 그 때마다 시그니쳐를 흔들어놓을 수준의 변경을 가하는 것은 쉽지 않은 일이기 때문이다.
그래서 근본적인 해결법으로 제시되는 것이 VPN 트래픽을 TLS로 캡슐화하는 것이다.

널리 알려진 바와 같이, 일단 TLS 세션이 성립되고 나면 회선을 감시하는 제 3자가 TLS 세션의 내용을 들여다보는 것은 MITM 공격을 수행하지 않는 이상 불가능하다. 그렇기 때문에 HTTPS를 이용하여 Warning.or.kr을 회피하는 것이 가능하고.
하지만 OpenVPN의 기본적인 암호화 프로토콜도 TLS이다. 그리고 중국 정부는 OpenVPN의 트래픽을 탐지, 차단하는 것에 성공하였다.

이것이 가능했던 이유는 OpenVPN의 TLS 세션 형성을 위한 핸드쉐이크가 시그니쳐로서 탐지되었기 때문이다. 이것을 특정함으로써 일반적인 TLS 트래픽과 OpenVPN 트래픽을(비록 내용은 모를지라도) 구분하는 것이 가능하다.
그렇다면 우리는 어떻게 이것을 우회할 수 있을까?
아주 단순한 결론이다. TLS 핸드쉐이크를 탐지한다면, ‘일반적인’ TLS로 한번 더 캡슐화해주면 될 뿐인 것이다.

 

이것을 위해 필요한 것이 stunnel이라는 프로그램이 되겠다. stunnel은 여기에서 다운로드 할 수 있으며, 임의의 서버-클라이언트 간 TLS 터널링을 제공한다.

 

stunnel을 서버/클라이언트에 인스톨하고, OpenVPN을 stunnel 터널을 통해 연결하면, 만리방화벽을 우회한 접속이 가능하다.
혹여나 중국에서 VPN 접속이 안 되어서 골머리를 앓고 있는 분이 계시다면, 한번 사용해 보기를 권한다.