TLS 1.3의 SNI 암호화에 대한 드래프트

프로필
LoG

2018. 7. 17. 23:25

이웃추가

한 분께서 알려주셔서 읽어보았습니다.
제가 잘못 해석하거나 이해했을 수도 있으니 제 설명은 주석이라 생각하시고 꼭 직접 읽어보시기 바랍니다.

이 문서에서는 TLS 1.3에서 어떻게 SNI 필드를 암호화 할 지에 대한 초안을 설명하고 있습니다.
여기서 제안한 핵심 방법은 DNS 프로토콜을 이용하여 공개키를 배포하고, 해당 공개키를 통해 SNI를 암호화 한 뒤에 보낸다는 겁니다.

먼저 서비스 제공자는 SNI를 암호화하기 위한 한 개 이상의 키 쌍을 생성하고 공개키들은 DNS의 TXT 필드를 통해 배포합니다. 공개키와 만료일 등등의 추가적인 데이터를 구조체 형태로 만들어서 Base64 인코딩을 하여 TXT 필드에 입력하는 것으로 보입니다. 이 공개키를 배포하는 도메인은 사용자의 요청 도메인에 _esni 라는 서브도메인을 붙힌 도메인이어야 한다고 나와있습니다. 
예를들면 사용자가 deadcoder.net에 접속하려고 DNS 조회를 할 때 SNI 암호화를 지원하는지 확인하기 위해 _esni.deadcoder.net의 TXT 필드를 확인하여 만약 데이터가 있다면 SNI 암호화를 지원하는 것으로 간주하고 데이터에 포함된 공개키를 사용하여 SNI 암호화를 한 통신을 진행합니다.
여기서 TXT 필드에 들어있는 공개키는 한 개 이상이어야 하고, 사용자에게 만약 여러 개의 키가 제공되었다면 그 중 하나의 키를 선택하여 SNI 암호화하여 서버에 전송하고 서버는 어떤 공개키를 사용하였는지와 관계없이 복호화를 할 수 있어야한다고 나와 있습니다.

이 초안의 난점은 HTTPS 서버와 DNS 서버가 서로 공조가 잘 되어야 한다는 겁니다. SNI 암호화에 사용되는 키의 만료기간이 다가오면 갱신을 필요한데, HTTPS 서버와 DNS 서버 동시에 반영이 되어야 합니다. HTTPS 서버야 보통 서비스 제공자가 직접 관리하는 경우가 많지만 DNS 서버는 따로 외부의 네임서버를 사용하는 경우가 많습니다. 이 경우에는 갱신 시 에로사항이 생길 여지가 많아보입니다.

위의 내용이 SNI 암호화에 대한 핵심인데, 문서에는 더 흥미로운 내용이 있었습니다. 문서의 3 장에 나오는 내용인데 공유 모드(Shared Mode)와 분리 모드(Split Mode)라는 겁니다.
제가 보기엔 공유 모드는 현재의 도메인 단위 가상호스팅과 동일하다고 보여집니다. 그리고 분리 모드는 클라우드플레어 서비스와 비슷하게 다른 서버 뒤에 숨겨져있는 형태같습니다. 다만 클라우드플레어처럼 캐싱을 하는게 아니라 단순히 릴레이를 하는 것으로 진짜 서버를 숨기는 모습입니다.
공유 모드는 현재의 가상호스팅이 SNI 정보를 보고 알맞은 서버 인증서와 데이터를 보내는 로직에 복호화가 추가된 것 뿐입니다. 분리 모드는 사용자가 직접 연결되는 서버와 실제 서비스를 제공하는 서버가 따로 존재합니다.
분리 모드에 대해 간단하게 표현하자면 프록시를 통한 통신이라고 볼 수 있겠습니다. 예를들어서 설명하기 위해 A 라는 사용자와 직접 연결되는 서버(1.1.1.1)와 B 라는 실제 서비스를 제공하는 서버(2.2.2.2)가 있고 해당 서비스의 도메인은 im.deadcoder.net으로 가정합시다.
DNS에 im.deadcoder.net의 IP는 1.1.1.1로 설정됩니다. 그러므로 저 도메인으로 접속하는 사용자는 A 서버에 연결이 됩니다. 당연히 SNI 암호화를 지원하기 때문에 _esni.im.deadcoder.net의 DNS TXT 필드에 공개키가 들어있습니다.
사용자는 SNI를 암호화하고 A 서버에 HTTPS Client Hello 패킷을 보냅니다.
A 서버는 SNI를 복호화하여 사용자가 im.deadcoder.net에 접속하고 싶다는 것을 알아냅니다. 그리고 이미 알고있던 B서버의 주소로 사용자가 보낸 HTTPS Client Hello 패킷을 그대로 전달해 줍니다. (어떠한 수정도 하지 않습니다.)
B 서버는 암호화된 SNI라던가 평문 SNI가 포함되어 있어도 무시하고 기본 설정된 서비스를 제공합니다.

분리 모드의 이점은 실제 서버를 숨길 수 있다는 점과 백엔드에 있는 숨겨진 서비스들이 많아질수록 검열이 힘들어진다는 겁니다. (정부의 마음에 들지 않는 사이트가 클라우드플레어를 사용하고 있다고 해서 무턱대고 클라우드플레어 서버에 대한 접속을 막았다간 엄청난 반발이 일어나는 것과 같습니다.)
문제점은 중간에 서버 하나를 더 거치게 되므로 병목현상의 위험이 있다는 겁니다.

나중에 이 초안이 통과가 된다면 분리 모드를 서비스하는 업체가 생길지도 모르겠습니다. 클라우드플레어 같은 거대 CDN 회사들은 무조건 서비스를 하지 않을까 생각됩니다. 그렇게되면 warning.or.kr이 유명무실해지는 날이 올지도 모릅니다.


LoG
LoG IT·컴퓨터

웹 개발이 주기능이지만 3D 모델링, 영상 제작, 웹 서버 관리, MFC 프로그래밍, 네트워킹, 웹 해킹 등 이상한 부가기능이 다수 장착된 괴상한 물건. 이 블로그의 대부분의 내용들은 퍼블릭 도메인이니 마음대로 쓰셔도 됩니다. 자세한건 공지사항 참조