본 글은 'HTTPS/DNS 차단 쉽게 이해하기' https://www.clien.net/service/board/park/13152618CLIEN 에서 이어지는 글로, 비유를 제거하고 기술적인 부분만을 다룹니다.
현행 HTTPS/DNS 차단 방식이 어떠한 방식으로 이뤄지고 있는지에 대해 설명하기 위한 글이며, 따라서 구체적인 네트워크의 작동 방식과 암호화 방식에 대한 내용은 생략하고 필요한 부분만을 다룹니다.
비전공자 분들의 이해를 돕기 위해 비유로만 설명을 했더니, 원치 않던 왜곡이 생겨 이를 바로잡고 더 자세한 이해를 원하시는 분들을 위한 글입니다.
이해를 돕기 위한 스크린샷들은 네트워크 패킷 캡쳐 및 분석 프로그램인 Wireshark 실행 화면에 대한 캡쳐로, https://www.wireshark.org/ 에서 직접 다운받으셔서 실제 오가는 패킷을 열어보실 수 있습니다. 제 MAC 주소, IP 주소 등은 모자이크 처리하였습니다.
먼저 HTTP 통신부터 보도록 하죠.
잘못된 형식의 이미지 링크입니다.
위의 패킷은 HTTP 요청 패킷입니다. 가장 먼저 보셔야 할 것은 Internet Protocol Version 4 레이어로, 송신 IP와 수신 IP 주소를 담고 있죠. ISP는 해당 정보를 통해 들어온 패킷이 어느 목적지로 가야하는지 파악하고, 해당 목적지로 패킷을 보내주게 됩니다.
아래의 Hypertext Transfer Protocol은 HTTP 패킷의 내용입니다. 보시다시피 HTTP는 암호화가 되지 않는 평문 통신이며, 제3자가 통신 내용을 전부 볼 수 있습니다.
따라서 기존에 시행되어왔던 HTTP 차단 방식은 HTTP 패킷을 열어, Host 헤더의 정보를 보고 해당 도메인이 차단 목록에 있다면 warning.or.kr로 보내버리는 방식으로 작동합니다.
여기서 중요한 것은 통신사가 원하는 목적지로 패킷을 보내기 위해서는 원래 IP 레이어만 보면 된다는 사실입니다. 즉, 차단을 위해 열어볼 필요가 없는 HTTP 패킷까지 열어보고 있다는거죠.
이전 글에서 HTTP 통신을 봉투에 들어간 편지에 비유한 이유도 이와 같습니다. 편지 봉투 = 암호화가 아닙니다. 이전 글의 비유에서 편지지 = HTTP 패킷이며, 봉투 = IP 패킷인거죠. 구조상으로도 HTTP 패킷이 IP 패킷으로 둘러싸인 구조니까요. (엄밀히 TCP 패킷으로 한번 더 둘러싸이긴 합니다만)
잘못된 형식의 이미지 링크입니다.
위의 스크린샷은 HTTP 응답 패킷으로, 앞서 말했듯 HTTP 통신은 평문 통신이기 때문에, 제3자가 내용도 전부 열람이 가능합니다. 물론 '열람할 수 있다'이지 '열람하고 있다'는 아닙니다. HTTP 차단을 위해서는 일단 HTTP 요청 패킷의 Host 헤더만 열어보고 있다니까요. 어쨌든 HTTP 패킷을 열어보고 있다는 사실은 동일합니다만.
HTTP 통신을 열어볼 수 있는건 통신사 뿐만 아닌, 통신 과정 중간에 있는 모든 제3자이며 따라서 보안에 매우 취약하기 때문에, 이를 보완하기 위해 HTTPS가 도입되었습니다. (공용 와이파이 쓰지 말라는 큰 이유 중 하나가 이겁니다)
잘못된 형식의 이미지 링크입니다.
위 스크린샷은 TLS 패킷의 일부입니다. 왜 HTTPS 패킷이 아니고 TLS 패킷이냐 하면, HTTPS 패킷은 HTTP + TLS 패킷이기 때문입니다. HTTP 패킷을 TLS 패킷으로 감싸서 암호화해서 보내는게 HTTPS거든요.
보시다시피 HTTP와 비슷하게 TLS 레이어가 TCP로 한겹, IP로 한겹 둘러싸인 형태입니다. IP 패킷으로 둘러싸였다는건 똑같죠? 그러니까 HTTPS면 IP도 암호화된다는건 개소리라는겁니다. IP 패킷을 암호화하면 통신사가 어디로 보내야할지 모르는데 어떻게 보내요...
아무튼, 더 엄밀하게 말하자면 위의 패킷은 HTTPS 연결을 시작하기 전 암호화 정보를 서로 교환하는 TLS Handshake 패킷입니다. 서로가 지원하는 암호화 방식, 암호화에 사용하는 난수, 공개키 등등을 교환하죠.
잘못된 형식의 이미지 링크입니다.
자... 여기 우리의 문제가 있습니다.
어찌된건지 TLS 표준을 정한 사람들은 설마 그거까지 까볼거란 생각은 못했는지, 까봐야 어디다 써먹겠냐는 생각이었지 모르겠지만 이 Handshake 과정에서 서버의 이름, 즉 SNI 필드를 암호화 하지 않고 평문으로 보내기로 결정합니다.
위의 예시처럼요. 해당 TLS 패킷이 www.clien.net으로 가고 있다는걸 SNI 필드는 평문으로 노출하게 됩니다.
그래서 현행 SNI 필드를 이용한 HTTPS 차단 방식은 모든 TLS Handshake 패킷을 까본 뒤, SNI 필드의 도메인 값이 차단 대상이면 차단시켜버리는 방식으로 작동합니다.
잘못된 형식의 이미지 링크입니다.
여기까지 읽었으면 TLS 패킷은 평문으로 전송되는 SNI 필드 등 일부 설정 정보를 제외하면 암호화된다는 사실은 매우 당연한데, 많은 분들이 HTTPS 패킷의 내용까지 까본다는 의미로 오해하시더군요.
SNI 필드 등 평문으로 전송되는 일부 메타데이터를 제외하면, HTTPS(TLS)의 내용은 위 스크린샷처럼 암호화되며 제3자가 복호화 할 수 없습니다.
뭐 NSA 쯤 되면 TLS를 실시간으로 풀어내는 미친짓을 성공했을지도 모르겠습니다만... 현재 이게 복호화가 가능하다면 심각한 보안 취약점입니다. 인증서 바꿔치기를 통한 중간자 공격 (MITM) 등을 이용하면 불가능하진 않지만, 그럼 바로 보안 경고가 뜨게 되어있죠.
잘못된 형식의 이미지 링크입니다.
Firefox에서 지원하는 ESNI를 쓰면, 위 스크린샷처럼 SNI 필드까지 암호화되어 전송되기 때문에 근본적으로 위의 문제를 막을 수 있습니다. (Wireshark에서 ESNI 필드를 아직 미지원해서 Unknown type으로 나오는데, Type 0xFFCE가 encrypted_server_name = ESNI 필드입니다. https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-5 참고하세요)
현재 Firefox 및 Cloudflare에 적용되었고, TLS 1.3 표준에 등재되기 위한 논의가 활발히 이뤄지고 있습니다. 즉, ESNI가 보급되면 현행 차단 방식은 무용지물이 된다는 소리죠.
Bonus) 갑자기 급부상한 GoodbyeDPI류의 우회 프로그램은 정보를 추가적으로 암호화 하는 것이 아닌, 패킷을 약간 변조하여 필터링 장비가 탐지하지 못하게 하는 방식으로 작동합니다. 예를 들어, 위의 SNI 필드를 여러개의 TCP 패킷으로 쪼개서 보내더라도 서버가 받아서 해석하는데는 표준상 문제가 없습니다만, 필터링 장비는 아직 쪼개진 패킷을 다시 합쳐서 보지 못하므로 탐지하지 못합니다.
이번에는 DNS에 대해서도 알아볼까요?
잘못된 형식의 이미지 링크입니다.
위 스크린샷은 KT DNS 서버인 168.126.63.1로 www.clien.net 도메인의 IP 주소를 요청하는 DNS 쿼리 패킷입니다.
보시다시피 DNS 또한 암호화되지 않은 평문 통신이며, 따라서 열어보거나 변조가 가능합니다.
현행 DNS 차단 방식은 크게 DNS 오염과 DNS 변조, 총 2가지 방식이 있습니다.
DNS 오염은 통신사 DNS 서버를 사용할 때만 적용 가능하며, 통신사 DNS로 들어오는 쿼리 요청 중 차단 도메인이 있다면 원래 사이트 IP 대신 warning.or.kr의 IP 주소를 대신 보내는 방식으로 작동합니다. 작동 원리 상 망에서 모든 DNS 쿼리를 열어볼 필요도 없고 통신사 DNS 서버만 바꾸면 되지만, 통신사 DNS 대신 구글 DNS 등 다른 DNS 서버를 이용하는 것으로 간단히 우회되죠.
그래서 작년 도입된 DNS 변조 방식은, 모든 DNS 패킷을 열어본 뒤 DNS 패킷의 내용에 차단 대상 도메인이 있다면 차단해버리는 방식으로 작동합니다.
잘못된 형식의 이미지 링크입니다.
이 역시 DNS 통신을 암호화 하는 것으로 해결 되겠죠? 위 스크린샷은 Cloudflare DNS 서버인 1.1.1.1에 www.clien.net의 IP 주소를 쿼리하는 DNS-over-HTTPS 패킷으로, 보시다시피 TLS로 암호화되며 내용을 확인할 수 없습니다.
여기까지 현행 HTTPS/DNS 차단 방식을 패킷 구조를 통해 알아봤습니다.
이것이 과연 '감청'이냐 문제는 법리적인 해석이 필요한 부분이겠습니다만, 제 생각은 통신사에서 라우팅에 필요하지 않은 정보까지 차단을 위해 열어보는 것은 엄연한 감청이며 프라이버시 침해라는 것입니다. 많은 분들이 비판하시는 부분도 마찬가지고요.
오늘 올라온 정부의 정책 브리핑에서는 '감청'을 ‘암호화’되어 송수신되는 전기통신 내용을 ‘열람 가능한 상태로 전환’하여 내용을 파악하는 행위로 정의하였습니다만 (https://m.news.naver.com/read.nhn?mode=LSD&mid=sec&sid1=123&oid=298&aid=0000268618), 감청의 개념을 암호화 통신에만 적용한다면 앞서 말한 HTTP 통신을 포함한 Telnet, FTP, DNS, SMTP 등 암호화되지 않고 평문으로 이뤄지는 수많은 프로토콜의 내용을 제3자가 엿보는 행동 또한 감청이 아니게 되겠죠.
일부 전문가 분들은 TLS Handshake 과정의 정보는 내용이 암호화되어 포함되기 전의 정보이므로 개인정보가 아니니 패킷 감청이라고 보기 어렵다고 보시는 분들도 있습니다만, 글쎄요. 과연 개인이 접속하는 사이트 도메인 주소가 개인정보가 아니라고 할 수 있을지 의문입니다.
http://www1.president.go.kr/petitions/522031
이번 HTTPS 차단 정책 반대 청원 링크로 글을 맺습니다. 틀린 부분에 대한 지적 환영합니다.
좋은 글 감사합니다.
생각해보면 warning 으로 보내던 방식과 동일한데 이렇게 감청 얘기가 나오니 안타깝습니다.
어떻게 차단했는지 보다 왜 차단했는지가 더 답답한 문제인데 말이지요...
그리고 그 패킷 다 열어보는 방식이 심각한 문제이고, 전 감청 맞다고 봅니다.
세계적으로 문제가 된다면 https 인증서 발급 등이 막히거나 국가차원에서 막아야 한다면 수사를 통한 사이트 폐쇄가 맞는데... 접속 차단은 접속하는 사람들을 잠재적 범죄자 취급하는게 아닌가 싶구요.
그동안 봤던 설명 글 중에 이 글이 최고인것 같습니다 :)
이를 이용하여 HTTP 표준은 한 개의 IP(서버)에 여러 호스트 이름을 할당하고 이 호스트 이름에 따라 다른 웹 사이트가 구동될 수 있도록 구성되어 있습니다. 최초 연결시 어떤 호스트(웹사이트를 열 것인지)를 판단하기 위해 HTTP 헤더에 호스트 이름이 포함됩니다.
이와 같은 원리로 HTTPS에서 한개의 서버에 여러 웹사이트를 구동하는 경우, 각각의 웹사이트는 별도의 인증서를 사용 할 수 있어, 연결이 들어온 경우 어떤 호스트에 지정된 서버인증서로 암호화를 할 것 인지를 판단하기 위해 암호화 채널을 열기 전 핸드쉐이크 메시지에 호스트 이름이 암호화 되지 않은 상태로 들어가는 것입니다.
제 개인적인 의견이지만 SNI 필드를 평문으로 전송하기로 한 가장 큰 이유는 성능 이슈라고 봅니다. 본문처럼 설마 그것까지 까볼까... 까봐서 뭐하려고? 했을 것이고 전부 다 암호화 하기엔 성능에서 손해를 보니 안한거죠.
물론 정식으로 인증되더라도 말씀하신대로 성능적인 손해도 무시할수는 없을 듯 하네요.
진짜 HTTPS 면 IP단 암호화 된다는 소리에 답답 터질뻔했는데, 이 글 보여줘야겠어요 ㅋㅋ
TLS 기반 VPN에서는 HTTPS와 비슷하게, 먼저 TLS 암호화 채널을 열고 이 안에 HTTP 메시지가 아니라 IP 패킷을 암호화해서 보내게 됩니다.
포탈을 열겠습니다.
아 다시 가보니 지금은 이해 하셨네요. 다행입니다 ㅋㅋ
저도 이런식으로 정리 잘해야 할텐데 말입니다.
저도 감청으로 보고 있습니다.
깔끔하네요.
개인적으로는, 감청이라는 단어보다 "기계적 차단" 부분을 더 뜯어봐야 한다고 봅니다.
차단한 로그를 남겨서 다른 곳에 활용하는지 vs 차단만 하고 로그는 남기지 않는지
만약 후자라면 현행법상 문제가 안될 겁니다.
전자라면 큰 문제가 되고요.
이 말씀처럼 HTTPS도 IP 레이어만으로도 차단이 가능한데, 무하러 SNI까지 열어보는 거죠?
IP만으론 차단 성능이 떨어지는 이유라든가 뭐가 있는 건가요?
모공에 올렸던 같은 글의 댓글에 자세한 내용이 있습니다. https://www.clien.net/service/board/park/13163648CLIEN
아 원 글에 쓰신 말씀은
"원래 ISP에선 IP레이어만 보면 되는데(원래 할 일), 차단을 위해서 HTTP 패킷까지 열어보고 있다" <-이건데,
"원래 ISP에서 차단을 위해선 IP 레이어만 보고 차단(원하는 목적지:워닝사이트)하면 되는데, HTTP 패킷까지 열어보며 차단하고 있다"
로 오해했습니다. 제가.
암튼 다른 분들도 얘기하듯이 비유없는 설명이 가장 깔끔한 것 같습니다. 세상에 완벽한 비유도 있을 수 없고, 받아들이는 사람마다 다른데, 왜 자꾸 비유로 설명을 하고, 또 그것이 설명을 잘하는 것처럼 여겨지는지 모르겠습니다.
전문가가 아닌 일반인이지만, 정말 불쾌할정도네요.. VPN을 결제를 하루빨리 해야겠군요
헛소리로 답변 못하게 했어야 했는데... 아쉽습니다.
글 내용관 약간 다른 부분인데 아시지 않을까 해서..
지금의 SNI 차단 전 DNS 오염이나 변조로 불리는 방식으로 사이트들이 차단되었다는데,
당시 HTTP가 아닌 HTTPS 사이트들은 마찬가지로 차단이 되었었나요?
아니면 차단되지 않았나요?
만약 차단되지 않았다면 그 이유는 무엇인가요?
국외 DNS 서버를 쓰는 일이 너무 흔해져서 차단효율이 급감하게 되면서 패킷 뜯어보는 방식으로 바뀐 것입니다.
다만 express vpn에서 계정 로그인이나 카드결제(카드번호입력하는 해외결제) 는 괜찮은것인지요?
https 사이트는 전송내용이 암호화되니 로그인정보나 결제정보도 안심할수있다고 보면 될까요
vpn에서 http 사이트인지만 조심하면 될까요?
혹시 감청이라고 생각하시는 이유가 편지봉투를 열어서 내용을 확인하는 행위자체가 문제라고 생각하시는거죠?
비록 편지 내용에 "Dear. 누구누구"만 볼 수 있다고 하라더라도 말이죠?
누구누구에게 언제 전화를 갈고 받았는가 라는 목록.
(통화 내용은 안나오죠. 그 목록엔)
그거 이통사의 장비는 실시간으로 보고 기록까지 하고있지만
정부를 비롯한 그 누구도 ‘영장’없이는 볼 수 없는 정보입니다.
그 사람이 누구랑 통화한다는 것 만으로도,
인터넷 사이트 어디를 돌아다닌다는걸 보는 것 만으로도,
해당 사람의 성향을 비롯해 여러가지를 알 수 있거든요.
민주국가에서 개인의 자유와 권리와 사생활을 침해할려면
‘영장’같은게 필요하다는건 상식입니다.
그리고 통신 비밀 보호법에서 ‘정의하는’ ‘감청’은
"감청"이라 함은 전기통신에 대하여 당사자의 동의없이 전자장치ㆍ기계장치등을 사용하여 통신의 음향ㆍ문언ㆍ부호ㆍ영상을 청취ㆍ공독하여 그 내용을 지득 또는 채록하거나 전기통신의 송ㆍ수신을 방해하는 것을 말한다.
입니다.
당사자의 동의 없이
전자장치를 통해 부호를 보고 그걸로
전기통신의 송수신을 방해하였으므로
통비법상 금지된 행위인 감청 입니다.