=============================
본래 TLS/SSL라는 프로토콜은 암호화를 위해 서버와 클라이언트(브라우저)가 암호화 키를 주고받는 과정이 필요합니다. 이를 Handshake라고 부르고요.
SSL이라는 프로토콜의 초기 Handshake 과정에는 SNI라는 항목이 아예 존재하지 않았습니다.
그러나 기술이 발전하면고, 하나의 서버에 여러 웹 사이트를 운용하는 것이 일반적이게 되면서 문제가 발생합니다. 이게 왜 문제가 되냐?
SNI 이전 클라이언트가 웹 서버에 접속하는 과정은 크게
1. 도메인 네임(clien.net 등)의 웹페이지를 호스팅하고 있는 서버의 IP 주소로 변환 후
2. 해당 IP의 서버에 접속
두 가지로 구분할 수 있습니다.
원래 모든 웹 페이지는 자신만의 고유한 암호화 키를 가지고 있어야 하는데, 만약 하나의 서버(IP)에서 여러 웹 사이트를 운용하게 되면 클라이언트가 서버에 접속할 때 어떤 암호화 키를 받아와야 하는지 알 수가 없게 됩니다. 이 부분은 그림으로 설명하는게 더 빠를 거 같습니다.
(1서버 1웹페이지일 경우)
(1서버 다 웹페이지 일 때, SNI가 없을 경우)
(SNI 도입)
그래서 도입된 것이 SNI입니다. 별거 없고, Handshake 과정에 도메인 네임을 추가해 주는 정도입니다. 이렇게만 해도 클라이언트가 어떤 웹 페이지에 접속하길 원하는 지 서버가 알 수 있죠.
SNI 암호화: 닭이 먼저, 달걀이 먼저?
그러나 이 SNI라는 놈을 불순한 용도로 악용하려는 불순한 놈들(대한민국정부 등등...)이 생깁니다. 원래 HTTPS가 도입되기 이전에는 사용자가 어떤 내용을 서버랑 주고받는지 백본단에서 모두 감청할 수 있었기에 사이트 차단이 쉬웠지만, HTTPS가 도입된 이후로 이게 힘들어졌죠. 그래서 생각해 낸 게 Handshake 과정에서 전달되는 SNI 패킷을 감청하여 블랙리스트에 오른 사이트에 접속하려 할 경우 연결을 끊어 버리는 거죠. 이를 SNI를 기반으로 한 차단이라고 흔히 부릅니다.
이게 가능한 이유는, SNI는 무조건 평문(암호화 되지 않은 문장)으로 전달되어야 하기 때문입니다. handshake 과정은 아직 암호화 키를 전달받기 전 단계이니까요. 암호화 키가 없는데 어떻게 암호화를 할까요?
그래서 나온게 DNS over HTTPS를 통한 SNI 암호화입니다.
먼저, DNS에 대해 잠깐 알아보겠습니다.
DNS는 도메인들에 대한 여러가지 정보를 담고 있는 서버입니다. 클라이언트는 DNS로부터 접속하려는 도메인의 IP 주소를 전달받습니다(위 그림처럼).
그리고 DNS over HTTPS는, 이런 DNS 서버에 암호화 된 통신을 함으로써 클라이언트가 어떤 사이트에 접속하려는지를 알 수 없게 하는 것이죠.
ESNI는 도청 장치가 DNS over HTTPS에서 전달되는 요청의 내용을 볼 수 없다는 점을 이용합니다. DNS 서버에 도메인에 해당하는 IP 주소 말고도, SNI를 암호화 할 수 있는 키를 심어두는 거죠.
그래서 이렇게...
(SNI 암호화 이전, 내가 어떤 서버에 접속하려 하는지 다 보임)
(SNI 암호화 후, 접속하려는 서버 정보를 제 3자가 알 수 없음)
ESNI가 작동하는 것입니다.
그러나 이 방법은 아직 표준 제정도 안된 기술이고, 위에서 말한 암호화 과정을 담당하는 OpenSSL이라는 라이브러리가 해당 기능을 지원하지 않아서 아직은 Cloudflare에서 호스팅하는 사이트에서만 작동한다는 것이 제일 큰 단점입니다.
빨리 해당 암호화 기술이 널리 상용화 되길 바랄 뿐입니다.
그게 무엇이 됐든 개인 감청이란 정당화 될 수 없으니