도메인 프론팅 차단에 두려워 말라, SNI 암호화는 개발되고 있다

지난 주말 캐나다 몬트리올에서 열린 IETF 해커톤에 참여한 애플, 클라우드 플레어, 패스틀리, 모질라 출신 엔지니어가 TLS 1.3에도 들어가지 못한 SNI 암호화 확장 구현을 위해 힘썼습니다.

HTTPS 통신에서 서버와 통신을 하는 과정에서 서버를 식별하는데 필요하지만 암호화 되지 않은채 전송되는 서버 이름 특정(SNI)이 무엇인지는 지난 글에서 잘 소개되어 있습니다.

보통 도메인은 서버 하나의 IP에 연결해 두는데, 그 경우 브라우저가 어느 서비스로 들어오려는건지 서버에선 판단할 수 없습니다. 그래서 SNI필드라는 TLS 확장을 사용해 접속할 서비스가 여기라고 초장부터 선언하는 것입니다. 

SNI 차단이 뭐야? TLS 1.3은 해결책이 될 수 있을까.

http://msm8994.tistory.com/38

이 SNI가 암호화되지 않았기 때문에 통신사나 국가가 DNS 암호화를 설정한 뒤에도 HTTPS 암호화 통신에 QoS나 접속차단 같은 검열을 적용할 수 있었습니다. 

IETF의 기안대로 구현된 서버는 현재 esni.examp1e.net 나 cloudflare-esni.com 로, BoringSSL(구글) NSS (모질라), picotls를 통해 구현되어 있습니다. 하지만 대부분은 아직 적용되어 있지 않는 탓에 암호화 메신저 앱 시그널은 도메인 프론팅을 사용해 이런 주소 차단을 쓴 검열을 우회하다가 아마존의 경고를 받았습니다.

아마존으로 옮겨간 이후 Signal은 아마존의 UAE 대상 쇼핑몰 사이트 Souq.com 트래픽으로 자신들의 트래픽을 위장했습니다. 그러자 아마존은 주소(도메인) 소유자의 허가를 받지 않은 채 그 도메인 행세를 했다며 클라우드프론트 이용약관 2장 1항 위반 경고 메일을 Signal에게 보낸 것입니다.

아마존이 도메인 프론팅을 막다. Signal의 계정을 정지시키겠다고 위협하기도

http://msm8994.tistory.com/7

모질라와 클라우드 플레어는 1.1.1.1 DNS 출시로 DNS 암호화 통신이 가능해진 이후에도 IETF가 표준을 정하지 못해 SNI가 평문으로 교환되는 현실을 안타까워했습니다.

또한 매튜 프린스 클라우드 플레어 CEO는 여러 컴퓨터를 거치는 통신으로 자신을 숨길 수 있는 Tor 통신 같은걸 쓰지 않으면 목적지 IP(서버)로의 트래픽을 숨길 수 없다고 말했습니다.

맺음말

IETF 표준이 잡지 못한 결함을 업계 선두주자가 고쳐내고 있습니다. SNI 암호화도 빨리 보급되어 검열로 눈가리고 아웅 하는게 아닌 확실한 수단으로 불법 사이트를 처벌하는 방법이 대세가 되길 바랍니다.