[Network]HTTPS SNI 차단 기술적 이해와 우회 방법

사실상 HTTPS SNI 차단은 아주 오래전에 나온 정책이다..
그 이후 생각날 때마다 한 번씩 포스팅해서 다뤄줘야 한다 생각했었는데 자꾸 미루다 지금에서야 포스팅해본다.

사이트 검열을 위한 차단 정책은 여러 가지가 있는데 나온 순으로 나열해보자면..
HTTP 차단 - DNS 차단 - HTTPS SNI 차단 순으로 나왔는데 이렇게 여러가지 정책이 나온 것에는 다 이유가 있다.

HTTPS SNI 차단만 알아보기에는 이해에 어려움이 있을 수 있어 기존에 있던 차단 정책들에 대해 간단히 알아보도록 하겠다.

---

HTTP 차단

가장 먼저 나온 HTTP 차단이다.

차단으로 인해 리다이렉트 되어 이동된 Warning.or.kr

사용자가 이용하는 웹 서비스의 대부분은 HTTP/HTTPS 프로토콜로 제공된다.
이 두 개의 프로토콜은 암호화가 적용되어있냐 안되어있냐 차이인데 쉽게 말해 HTTP는 데이터를 평문 형식으로 통신하는 것이고, HTTPS는 HTTP에 SSL/TLS 프로토콜이 적용 되어 암호화 통신을 하는 것이다.

즉 HTTP는 제 3자 또한 내용을 열어 확인할 수 있다는 소리다.
이 말은 HTTP로 통신되는 '사이트의 헤더 호스트 URL' 과 현재 '사용하고 있는 ISP 통신사의 차단 블랙리스트에 있는 사이트의 URL' 과 일치한다면 우리가 흔히 알고 있는 차단 웹 사이트(warning.or.kr)로 리다이렉트 되는 것이다.

하지만 평문으로 데이터가 그대로 노출된다는 HTTP의 취약함 때문에 취약점 공격들 중 하나인 'Man In The Middle Attack' 라고 불리는 '중간자 공격' 을 통해 암호화되지 않은 통신의 중요한 데이터를 가로채는 공격 등 이러한 취약점 때문 HTTPS를 이용하는 것이다.

HTTPS 프로토콜로 웹 서비스가 변화함에 따라 차단 또한 한계가 발생하게 된다.
즉 기존에 HTTP 차단 방식으로는 HTTPS 프로토콜을 차단할 방법이 없다는 것이다.

그래서 나온 것이 'DNS 차단' 이다.

---

DNS 차단

DNS 차단은 사용자가 가입한 ISP에서 제공하는 DNS 서버에서 불법적인 접근이 발생하면 마찬가지로 warning.or.kr 사이트로 응답해주는 것이다.

HTTPS 프로토콜은 사이트의 통신 패킷을 암호화해주는 것이지 DNS Query까지 암호화해주는 건 아니기 때문에 이러한 차단 방식이 가능한 것이다.

위 사진은 현재 사용 중인 KT DNS 서버인 '168.126.63.1' 으로 www.naver.com 도메인의 아이피 주소를 요청하는 DNS Query 패킷이다.

쿼리 내용을 볼 수 있듯이 평문 통신으로 이루어져 있어 직접 열어서 변조 또한 할 수 있다.
즉 해당 ISP 통신사에서 DNS 패킷을 열어본 뒤 블랙리스트에 있는 사이트에 접속하려 한다면 warning.or.kr 사이트로 리다이렉트 시켜주는 방식이다.

결론적으로 이런 방식은 DNS Query 또한 암호화가 되는 해외 DNS 1.1.1.1(Cloudflare), 8.8.8.8(Google Public) 로 변경하여 접속하면 간단히 우회할 수 있었다.

그래서 정부는 이렇게 DNS을 변경하여 우회해서 들어가는 방법들에 대한 방안으로 내세운 것이 바로 HTTPS SNI 차단인 것이다.

---

HTTPS SNI 차단

정부는 HTTPS 통신을 DNS 차단이 아닌 HTTP 차단처럼 직접적으로 차단하는 방법을 찾아내는데 그게 바로 SNI라는 필드 부분을 건드리는 것이다.

SNI가 무슨 역할을 하는지 간단히 알아보겠다.

Crisp 채팅 서비스의 SNI 정보

SNI는 Server Name Indication의 약자로 TLS Handshaking에서 발생되는 TLS 프로토콜의 확장형 중 하나인데 TLS 인증서가 적용된 웹 사이트를 서비스하는데 관련된 문제로 이를 해결하기 위해 나온 것이 SNI이다.
(여기서 TLS Handshaking은 간단히 말해 암호화 방식, 키 값, 공개키 등등을 교환하는 과정이다.)

기본적으로 하나의 서버를 운영할 때 하나의 서버 IP와 하나의 도메인이 1:1 식으로 매핑되어 돌아가는 방식인데 웹 호스팅 서비스같이 하나의 IP 주소에 여러 개의 도메인을 매핑시켜서 운영하는 경우에 보낼 TLS 인증서를 특정하지 못하는 문제점이 발생된다.

이를 해결하기 위해서 Handshaking 과정에서 도메인에 연결된 웹 사이트에 호스트명을 지정해주어서 서로 다른 도메인에 각각 다른 인증서를 보낼 수 있게 만든 솔루션이 바로 SNI 인 것이다.

즉 HTTPS는 사이트 내에서 통신되는 데이터가 암호화가 되는 것이지 그 사이트와 통신하기 위한 과정은 암호화가 되지 않는다는 것이다.

https sni로 차단된 모습

그렇기 때문에 정부는 TLS Handshaking 패킷을 까 본 뒤 SNI 필드 정보를 보고 차단 대상에 해당된다면 RST 패킷을 보내 접속시키지 못하도록 하는 것이다.

Pornhub.com RST 패킷으로 차단

더 엄밀히 말하자면 TLS Handshaking 은 'Client hello' 라는 패킷 즉 사용자가 지원하는 암호화 방식이 무엇이고 보내는 패킷의 세션 ID가 무엇인지 등 TLS 세션이 성립하기 위한 여러 가지 정보들이 있는 패킷을 클라이언트가 서버에게 전달하고 핸드셰이크를 게시하는 것이고 이 메시지를 받은 서버는 받았다는 질의응답 'Server hello' 를 전달하여 서버 자체의 공개키와 암호화를 위한 인증서를 교환하여 링크를 구성하게 되고 이후부터 통신 준비를 하는 것인데 'Client hello' 에서 바로 SNI 정보를 확인 한 뒤 'Reset' 패킷을 보내 차단하는 것이다.
(TCP Flag인 RST 패킷을 차단하는 프로그램을 만들어 사이트에 접속할 수 있는 방법도 있었다.)

SNI 차단 정책이 나오고 잠깐 오해의 소지가 있었던 내용이 HTTPS에서 통신되는 암호화된 내용까지 전부 다 까 봐서 차단한다는 분들도 있었지만... 이로써 제대로 이해하고 갔으면 좋겠다..
(실시간으로 TLS 패킷을 복호화하여 통신할 수만 있다면 뭐.. 슈퍼 컴퓨터라면 가능할지도?..)

---

HTTPS SNI 차단 우회 방법

 

우회 방법을 말하기 전 짚고 넘어가야할 부분이 있다.

Cloudflare DNS(1.1.1.1)로 변경하여서만 뚫린다는 소리가 있는데.. 개소리이다.

 

몇몇 블로거분들이 1.1.1.1로 변경하여 SNI 차단을 우회할 수 있다고 포스팅을 해놓았는데 아마 ISP에서 RST 패킷을 보내는 과정에서 가끔 트래픽이 RST 패킷을 무시하고 넘어가버리는 현상이 있다.

넘어가버린 시점에서 정상적인 통신이 이루어졌을때 장시간동안 접속을 끊지 않은 이상 계속해서 정상통신이 이루어진다.

(오랜시간 접속 안하면 다시 RST 차단)

 

(RST로 차단되었다가 갑자기 TLSv1.3 으로 다시 통신되는 모습)

 

블로거분들이 이것을 보고 잘못 이해한건가 싶다.

+ 추가로 DNS를 굳이 변경하지 않아도 뚫릴 때가 있다.

• (정확한 이유는 모르겠지만 많은 양의 HTTPS 트래픽 발생, 그에 대한 차단 장비 부하, 일시적 오류 등등 자세히는 모르겠다. )

 

즉 DNS 변경만으로는 SNI 차단 우회랑 연관성이 없다..

 

그리고 유독 클라우드 플레어가 적용된 사이트 위주로 잘 뚫리는 경향이 있는데 클라우드 플레어 자체에서 TLSv1.3과 ESNI를 지원하여 영향이 있는 것 같다?..(이것 또한 RST 패킷에 대한 일시적 오류일 가능성이 큼)

• (사실 이 부분도 잘 모르겠는게 클라우드 플레어가 적용된 사이트들도 다 뚫리는것이 아닌 어떤 곳은 뚫리고 어떤 곳은 안뚫리는 현상이 일어난다. 그리고 그 뚫리는 사이트 마저도 금방 막혀버린다.)

이렇게 별다른 설정을 하지 않았는데 그냥 뚫리는 현상은 아마 차단하는 데 있어서 일시적 오류일 가능성이 제일 크다.

다만 그 일시적 오류가 꽤나 빈번하다?..

 

결론적으로 클라우드 플레어에서 사용하는 ESNI를 적용시켜서 제대로 우회할려면 내가 사용하는 브라우저 또한 ESNI를 지원해야 한다.

엄밀히 말하면 통신의 순서가 DNS Query - TCP Handshaking - TLS Handshaking 순 인데 암호화 키 인증서 전달을 Dns Query 부분으로 앞당겨서 Cloudflare에서 지원하는 DoH을 통해 (사용 브라우저에서 DoH 설정) DoH에 SNI를 암호화시키기 위한 정보를 끼워 넣고 DoH를 통해 암호화된 DNS Query/Response로 정보를 가져오는 것이다.

 

하지만 ESNI를 지원하는 브라우저는 현재 파이어 폭스밖에 없고 최신 버전의 파이어폭스는 ESNI 지원을 종료하고 ECH라는 Client hello 패킷 자체를 암호화해버리는 솔루션을 지원하는데 이것이 문제가 ESNI 처럼 접속하는 사이트 또한 솔루션을 지원해야 하는데 ECH를 지원하는 사이트는 거의 없다..

• (+ 파폭 ESR버전이라고 장기지원용 버전을 사용하면 ESNI 솔루션을 다시 사용할 수 있다고 한다.)
• (+ 나무위키 왈 : 2021년 10월 12일 클라우드 플레어에서 드디어 일부 무료 영역의 네트워크에 ech를 사용할 수 있도록 하겠다고 한다.) https://blog.cloudflare.com/handshake-encryption-endgame-an-ech-update/

Handshake Encryption: Endgame (an ECH update)

 

먼저 우회 방법들 중 'VPN, 해외 웹 프록시, 수동 MTU 수정' 같은 네트워크 속도에 크게 영향을 줄만한 방법들은 언급 안함

 

첫 번째 방법

위에서 언급 했듯이 두 가지 조건을 충족시켜야 하는 방법

1. ESNI 또는 ECH을 지원하는 브라우저를 사용할 것.

2. 마찬가지로 ESNI와 ECH를 지원하는 사이트에 접속 할 것. 즉 클라우드 플레어 서비스가 적용된 사이트가 대상이 되어야 함. 

 

장점. 속도에 영향 없음, 가장 정론적인 방법

단점. ESNI, ECH를 지원하지 않는 사이트들은 우회 못함. 설정하기 귀찮고 고작 우회 하나 하는것에 비효율적임.(브라우저 doh설정, esni 활성화 등등..)

 

두 번째 방법

1. 패킷 변조 프로그램을 이용

GoodByeDPI, 유니콘 HTTPS, Intra 등 패킷을 쪼개거나 특정 패킷의 헤더 값을 다르게 해서 보낼 수 있는 프로그램을 이용.

 

장점. 사실상 가장 편리한 방법. 스마트폰에선 가장 편리한 방법, 속도에 구애받지 않음

단점. 단순 우회에만 초점을 둔 원리이기에 보안x. PC에서 많이 사용되는 Goodbyedpi는 업데이트가 중단되어 점점 막혀가는 중 (pornhub.com 막힘)

 

세 번째 방법

1. Cloudflare WARP을 이용

장점.  VPN과 비슷한 효과를 누릴 수 있음

클라우드 플레어의 네트워크를 경유하여 통신하는 것이기 때문에 클플 내에서 DoH까지 지원해주고 ESNI는 물론 중계서버로 프록시 개념처럼 클라우드 플레어를 통해 통신하는 것이기 때문에 pornhub.com 같은 ESNI를 지원하지 않는 곳도 접속 가능하다. (속도도 애초에 CDN 서비스라 빠름)

PC에서 사용하기 적합함

 

단점. 패킷 변조 프로그램과 같이 속도에 대해서 아예 영향이 없진 않지만 사용하는데 있어서 거의 불편함을 못느낌.

즉 단점 없음

 

 

 

읽었을 때 틀린 부분이나 궁금한 부분 있으면 댓글 달아주면 감사하겠습니다.!!