1 2 3 4 5 6 L

Page Header > Subtitle

HTTPS/DNS 차단 이해하기

현행 HTTPS/DNS 차단 방식이 어떠한 방식으로 이뤄지고 있는지에 대해 설명하기 위한 글이며, 따라서 구체적인 네트워크의 작동 방식과 암호화 방식에 대한 내용은 생략하고 필요한 부분만을 다룹니다.

 

비전공자 분들의 이해를 돕기 위해 비유로만 설명을 했더니, 원치 않던 왜곡이 생겨 이를 바로잡고 더 자세한 이해를 원하시는 분들을 위한 글입니다.

 

이해를 돕기 위한 스크린샷들은 네트워크 패킷 캡쳐 및 분석 프로그램인 Wireshark 실행 화면에 대한 캡쳐로, http://www.wireshark.org/ 에서 직접 다운받으셔서 실제 오가는 패킷을 열어보실 수 있습니다. 제 MAC 주소, IP 주소 등은 모자이크 처리하였습니다.

 

 

먼저 HTTP 통신부터 보도록 하죠.

 

14cf7cd31cc850.png?w=780&h=30000&gif=tru

위의 패킷은 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 패킷으로 한번 더 둘러싸이긴 합니다만)

 

14d02a06156f16.png?w=780&h=30000&gif=tru

 

위의 스크린샷은 HTTP 응답 패킷으로, 앞서 말했듯 HTTP 통신은 평문 통신이기 때문에, 제3자가 내용도 전부 열람이 가능합니다. 물론 '열람할 수 있다'이지 '열람하고 있다'는 아닙니다. HTTP 차단을 위해서는 일단 HTTP 요청 패킷의 Host 헤더만 열어보고 있다니까요. 어쨌든 HTTP 패킷을 열어보고 있다는 사실은 동일합니다만.

 

HTTP 통신을 열어볼 수 있는건 통신사 뿐만 아닌, 통신 과정 중간에 있는 모든 제3자이며 따라서 보안에 매우 취약하기 때문에, 이를 보완하기 위해 HTTPS가 도입되었습니다. (공용 와이파이 쓰지 말라는 큰 이유 중 하나가 이겁니다)

 

 

 

14d0606c949d91.png?w=780&h=30000&gif=tru

 

위 스크린샷은 TLS 패킷의 일부입니다. 왜 HTTPS 패킷이 아니고 TLS 패킷이냐 하면, HTTPS 패킷은 HTTP + TLS 패킷이기 때문입니다. HTTP 패킷을 TLS 패킷으로 감싸서 암호화해서 보내는게 HTTPS거든요.

 

보시다시피 HTTP와 비슷하게 TLS 레이어가 TCP로 한겹, IP로 한겹 둘러싸인 형태입니다. IP 패킷으로 둘러싸였다는건 똑같죠? 그러니까 HTTPS면 IP도 암호화된다는건 개소리라는겁니다. IP 패킷을 암호화하면 통신사가 어디로 보내야할지 모르는데 어떻게 보내요...

 

아무튼, 더 엄밀하게 말하자면 위의 패킷은 HTTPS 연결을 시작하기 전 암호화 정보를 서로 교환하는 TLS Handshake 패킷입니다. 서로가 지원하는 암호화 방식, 암호화에 사용하는 난수, 공개키 등등을 교환하죠.

 

 

14d15158ac9d1b.png?w=780&h=30000&gif=tru

 

 

자... 여기 우리의 문제가 있습니다.

 

어찌된건지 TLS 표준을 정한 사람들은 설마 그거까지 까볼거란 생각은 못했는지, 까봐야 어디다 써먹겠냐는 생각이었지 모르겠지만 이 Handshake 과정에서 서버의 이름, 즉 SNI 필드를 암호화 하지 않고 평문으로 보내기로 결정합니다.

 

위의 예시처럼요. 해당 TLS 패킷이 www.clien.net으로 가고 있다는걸 SNI 필드는 평문으로 노출하게 됩니다.

그래서 현행 SNI 필드를 이용한 HTTPS 차단 방식은 모든 TLS Handshake 패킷을 까본 뒤, SNI 필드의 도메인 값이 차단 대상이면 차단시켜버리는 방식으로 작동합니다.

 

 

14d0e224d7ef14.png?w=780&h=30000&gif=tru

 

여기까지 읽었으면 TLS 패킷은 평문으로 전송되는 SNI 필드 등 일부 설정 정보를 제외하면 암호화된다는 사실은 매우 당연한데, 많은 분들이 HTTPS 패킷의 내용까지 까본다는 의미로 오해하시더군요.

 

SNI 필드 등 평문으로 전송되는 일부 메타데이터를 제외하면, HTTPS(TLS)의 내용은 위 스크린샷처럼 암호화되며 제3자가 복호화 할 수 없습니다.

 

뭐 NSA 쯤 되면 TLS를 실시간으로 풀어내는 미친짓을 성공했을지도 모르겠습니다만... 현재 이게 복호화가 가능하다면 심각한 보안 취약점입니다. 인증서 바꿔치기를 통한 중간자 공격 (MITM) 등을 이용하면 불가능하진 않지만, 그럼 바로 보안 경고가 뜨게 되어있죠.

 

14d12dba07f2be.png?w=780&h=30000&gif=tru

 

 

Firefox에서 지원하는 ESNI를 쓰면, 위 스크린샷처럼 SNI 필드까지 암호화되어 전송되기 때문에 근본적으로 위의 문제를 막을 수 있습니다. (Wireshark에서 ESNI 필드를 아직 미지원해서 Unknown type으로 나오는데, Type 0xFFCE가 encrypted_server_name = ESNI 필드입니다. http://tools.ietf.org/html/draft-ietf-tls-esni-01#section-5 참고하세요)

 

현재 Firefox 및 Cloudflare에 적용되었고, TLS 1.3 표준에 등재되기 위한 논의가 활발히 이뤄지고 있습니다. 즉, ESNI가 보급되면 현행 차단 방식은 무용지물이 된다는 소리죠.

 

 

Bonus) 갑자기 급부상한 GoodbyeDPI류의 우회 프로그램은 정보를 추가적으로 암호화 하는 것이 아닌, 패킷을 약간 변조하여 필터링 장비가 탐지하지 못하게 하는 방식으로 작동합니다. 예를 들어, 위의 SNI 필드를 여러개의 TCP 패킷으로 쪼개서 보내더라도 서버가 받아서 해석하는데는 표준상 문제가 없습니다만, 필터링 장비는 아직 쪼개진 패킷을 다시 합쳐서 보지 못하므로 탐지하지 못합니다.

 

 

 

이번에는 DNS에 대해서도 알아볼까요?

14d12a46ba5835.png?w=780&h=30000&gif=tru

 

위 스크린샷은 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 패킷의 내용에 차단 대상 도메인이 있다면 차단해버리는 방식으로 작동합니다.

 

 

14d1b685022566.png?w=780&h=30000&gif=tru

 

이 역시 DNS 통신을 암호화 하는 것으로 해결 되겠죠? 위 스크린샷은 Cloudflare DNS 서버인 1.1.1.1에 www.clien.net의 IP 주소를 쿼리하는 DNS-over-HTTPS 패킷으로, 보시다시피 TLS로 암호화되며 내용을 확인할 수 없습니다.

 

 

 

 

 

여기까지 현행 HTTPS/DNS 차단 방식을 패킷 구조를 통해 알아봤습니다.

 

이것이 과연 '감청'이냐 문제는 법리적인 해석이 필요한 부분이겠습니다만, 제 생각은 통신사에서 라우팅에 필요하지 않은 정보까지 차단을 위해 열어보는 것은 엄연한 감청이며 프라이버시 침해라는 것입니다. 많은 분들이 비판하시는 부분도 마찬가지고요.

 

오늘 올라온 정부의 정책 브리핑에서는 '감청'을 ‘암호화’되어 송수신되는 전기통신 내용을 ‘열람 가능한 상태로 전환’하여 내용을 파악하는 행위로 정의하였습니다만 (http://m.news.naver.com/read.nhn?mode=LSD&mid=sec&sid1=123&oid=298&aid=0000268618), 감청의 개념을 암호화 통신에만 적용한다면 앞서 말한 HTTP 통신을 포함한 Telnet, FTP, DNS, SMTP 등 암호화되지 않고 평문으로 이뤄지는 수많은 프로토콜의 내용을 제3자가 엿보는 행동 또한 감청이 아니게 되겠죠.

 

일부 전문가 분들은 TLS Handshake 과정의 정보는 내용이 암호화되어 포함되기 전의 정보이므로 개인정보가 아니니 패킷 감청이라고 보기 어렵다고 보시는 분들도 있습니다만, 글쎄요. 과연 개인이 접속하는 사이트 도메인 주소가 개인정보가 아니라고 할 수 있을지 의문입니다. 

0
0
이 글을 페이스북으로 퍼가기 이 글을 트위터로 퍼가기 이 글을 카카오스토리로 퍼가기 이 글을 밴드로 퍼가기
captcha
자동등록방지 숫자입력

Server

번호 제목 글쓴이 날짜 조회수
67 Simple CORS using .htaccess file. 미도어묵 03-08 611
66 HTTPS/DNS 차단 이해하기 미도어묵 02-14 643
65 HTTP proxying cloudflare custom port 미도어묵 01-02 623
64 Nginx HTTPS Let's Encrypt 무료 인증서 설치하기 우분투 16.04 미도어묵 10-17 321
63 리눅스 sftp log 남기기 미도어묵 01-25 415
62 PHP | [CentOS 7] PHP 5.4 to PHP 7.1 업그레이드 미도어묵 01-22 553
61 우분투(ubuntu) kernel 업그레이드 시 boot 용량 부족, 의존성 문제 미도어묵 01-11 463
60 firewall.sh , reboot.sh 미도어묵 01-10 305
59 사용자 계정 추가, mysql 계정추가등 shell script 미도어묵 01-10 304
58 Ubuntu 한 서버에서 PHP, JSP 동시에 사용하기 미도어묵 01-08 323
57 Ubuntu JSP서버세팅 미도어묵 01-08 303
56 pid 값으로 강제 종료 스크립트. 미도어묵 12-22 297
55 mysql(mariadb) 테이블별 mysqldump 백업 - shell script 미도어묵 12-22 309
54 Cloudflare - Get visitors real IP without extension(cloudflare_realip.conf) 미도어묵 12-18 297
53 shell script 일정 이상 cpu 점유시 강제 kill 미도어묵 12-07 310
52 리눅스 모니터링 툴 htop 미도어묵 11-09 353
51 [OS X, Ubuntu] 터미널에서 tmux 사용해 보기 미도어묵 11-09 373
50 우분투 보안 업데이트만 설치하기 미도어묵 11-07 337
49 nginx config , rewrite, allow, deny(web && node) 미도어묵 11-01 300
48 특정 IP만 SSH 접속 허용하기 미도어묵 09-30 345