알리는 말

본 문서에 정확하지 않은 내용이 있을 수 있습니다. 수정 문의는 메일(cr3ux53c@loopback.kr) 또는 댓글로 남겨주십시오.

 

제1장 서    론

제1절 개요

최근 문화체육관광부에서 발표한 ‘웹툰 등 불법유통 해외사이트 집중 단속 및 정품 이용 캠페인 연계 실시[1]’에 대한 논란이 불거지고 있다. 표면 상 목적은 불법 유통물 단속 등의 저작권 보호 방침이나 그 과정이 깊은 패킷 분석(DPI)과 DNS 쿼리를 변조시키는 강수를 둔다는 데에서 정부의 인터넷 검열을 우려 하는 목소리가 나오고 있다.

그림 1 – DNS 변조를 통한 사이트 우회

이를 계기로 DNS가 일반적으로 작동되는 과정과 암호화 프로토콜을 적용한 상태의 통신 과정을 간략히 살펴본다. 특히 평문 DNS 쿼리의 취약점을 확인하고 이를 방어하는 암호화 통신을 구축한다. 끝으로 DNS 암호화 프로토콜의 한계와 추후 나타날 암호화 기술에 대해 소개 및 정리한다.

제2절 암호화의 필요성

 현재 쓰이고 있는 인터넷 기술의 대부분은 아주 오래전에 개발되어 정보의 보안을 감안하지 않은 낡은 기술이며, 현대의 네트워크 모델이나 상황과는 맞지 않는 것이 꽤나 있다. ARP는 스푸핑에 취약하며, TCP는 지나치게 큰 오버헤드를 가진다. DNS 쿼리는 암호화되지 않은 평문 상태로 DNS 서버에 질의를 시도한다.

 일반적인 네트워크 환경에서 시연 테스트로 사용된 사이트인 testdrive.loopback.kr (121.191.223.83)로 처음 접속하는 클라이언트 (175.212.71.86)가 있다고 하자.

그림 2 – 평문 DNS 쿼리문

그림 2는 해당 클라이언트가 잘 알려진 ISP인 KT(Korea Telecom)社의 공개 DNS 서버(168.126.63.1)로 DNS 쿼리를 전송하는 패킷을 네트워크 회선 중간에서 수집해 본 화면이다. 강조된 부분을 보면 쿼리문에 포함된 도메인이 그대로 노출되는 것을 볼 수 있다. 이는 ISP나 조직 내 네트워크 관리자가 (TLS 적용 시)전송되는 패킷의 페이로드는 볼 수 없을 지 몰라도 클라이언트가 언제 어느 웹사이트로 접속하는 지는 감청할 수 있다는 얘기가 된다. DNS 서버를 ISP의 DHCP 서버에서 받아오는 대신 잘 알려진 타사의 DNS 주소(1.1.1.1, 8.8.8.8, 9.9.9.9 등…)로 변경해도 쿼리가 암호화되는 것은 아니기에 결국 개인의 프라이버시에 위협이 된다. 더 나아가 중간자 공격 다시 말해, DNS 스푸핑에 취약해 공격자가 쿼리문의 도메인을 변조할 수 있다. 사용자는 정확한 도메인명을 입력했음에도 공격자가 심어 놓은 Fake-site로 접속할 수 있다.

2018년 현재 서비스 중인 대부분의 운영체제는 DNS 암호화 프로토콜을 네이티브 지원하지 않는다.[2] 또한 클라이언트 뿐만 아니라 DNS 서버도 해당 프로토콜을 지원해야 한다. 2018년 현재 IBM Quad9, Cloudflare, Google이 대표적으로 암호화된 DNS 프로토콜을 지원[3][4]한다. 고로 현 시점에서 최종 사용자는 third-party 소프트웨어를 통해 DNS 암호화를 구현해야 한다.

3절 시연의 목적

 몇 가지 프로토콜의 구현을 시연함으로써 DNS 쿼리의 암호화 통신이 이루어지는 과정을 살펴보며 앞서 언급한 취약점을 해결할 방법을 제시한다. 또한 암호화 프로토콜의 통신 과정을 모식화 하여 사용자의 이해를 돕는다.

제2장 시    연

1절 시연 계획

 본 시연의 목적은 간단히 패킷 수집을 통한 암호화 여부를 관찰하는 것이 핵심이므로 가상 머신을 설치해 비용을 줄여 진행하는 것으로 한다.

 시연에서 구현할 프로토콜은 두가지로 ‘DNS Over HTTPS’ (이하 DoH)‘DNSCrypt’가 있다. DoH는 이름에서 알 수 있듯이 패킷을 TLS로 암호화한 후 일반적인 HTTP GET/POST 통신을 하듯이 DNS 서버에 쿼리를 전송한다. 3자 입장에서는 일반적인 웹 쿼리로 위장 시킬 수 있다. DNSCryptDNS 쿼리 안의 페이로드를 암호화하여 전송을 시도한다.

2절 시연 환경 구성

 실험 PC에 호스트형 하이퍼바이저를 설치하고 VM을 생성했다. 외부 망은 호스트 PC의 물리 NIC로 연결되지만 ISP로부터 새로운 IP를 할당 받기 위해 bridge 모드로 가상 NIC를 물렸다.

 클라이언트의 운영체제나 웹 브라우저에서 DNS 암호화 프로토콜을 지원하지 않으므로 클라이언트 자체에 DNS Proxy 모드의 DNS 중계 서버를 구축하여 구현한다. 네트워크 어댑터의 DNS 서버를 루프백(127.0.0.1)으로 설정해 모든 DNS 요청이 DNS Proxy를 경유해 DNS 암호화를 지원하는 DNS 서버와 통신한다.

그림 3 – DNS Proxy 시연 모식도

앞서 언급했듯이 DNS 암호화 프로토콜은 클라이언트와 서버가 모두 해당 프로토콜을 지원해야 한다. GitHub에 공개된 ‘dnscrypt-proxy[5]’가 이를 구현한 대표적인 프로젝트다. 데몬을 실행한 후 네트워크 어댑터의 DNS 서버를 루프백으로 설정하면 서버 구축은 끝난다. DNS 캐시를 비우고 구축 전과 후를 나누어 특정 사이트를 접속하여 DNS 쿼리 암호화 여부와 사이트 정상 접속 여부를 확인한다.

3절 시연

시연을 위해 국내 ISP인 KT社에서 차단(2018년 11월 기준)하고 있는 사이트로 bittorrent.com을 선정했다. 이 사이트는 토렌트 클라이언트를 배포하고 있는 공식 사이트로 네임 서버 조회 시 정확한 IP가 반환되지 않는다.

그림 4 – KT DNS에서 쿼리 결과

먼저 DoH로 통신하는 과정을 분석해보았다.

그림 5 – DNS Over HTTPS 통신 패킷

 TLS hand-shaking 직후의 10, 11 라인이 핵심 송/수신 과정이며, TLS가 적용된 상태이므로 일반적인 웹 쿼리와 구분하기 힘들다. 이 쿼리는 DNS 서버에 잘 전달되며, DNS 측에서도 암호화된 패킷을 잘 전달했다.

그림 6 – DNS Over HTTPS에서 쿼리 결과

그림 6와 같이 정확한 IP를 반환했다. 웹 사이트 또한 잘 접속되었다.

그림 7 – Bittorrent 웹 사이트

다음은 DNSCrypt 프로토콜을 구현하여 시연해 본다.

그림 8 – DNSCrypt 통신 패킷

제3장 결    론

제1절 결과 분석

대표적인 두가지 암호화 프로토콜을 구현하고 통신 패킷의 형태를 살펴봤다.

DoH는 일반적인 웹 쿼리 방식으로 쿼리문을 전송하는데 표준 TLS 통신 과정과 유사해 제 3자가 이 차이를 인지하기 어렵다.

그림 8의 DNSCrypt의 경우 일반적인 DNS 패킷에 페이로드 데이터만 암호화했기 때문에 DNS 쿼리를 시도하는 것은 알 수 있으며, 오버헤드의 다른 메타데이터는 수집될 가능성이 있다.

제2절 한계와 추후 대응 방안

두 프로토콜을 통해 결국 웹 사이트의 IP 주소를 알아낸다 해도 TLS handshake 단계에서 웹 서버로부터 인증서를 요구하는 과정에서 SNI(Server Name Indication) 정보가 노출된다. 웹 서버의 가상 호스트 기능을 구현하는 과정에서 SNI는 반드시 전달되어야 하는 정보이므로 결국 SNI를 암호화하지 않는 완전한 암호화 통신은 불가능하다. 표준 TLS 1.3 버전 초안에 Encrypted SNI 규격이 논의되고 있지만 표준이 완성되고 범용적으로 쓰이려면 시간이 필요하다.

추후에 정부 기관이나 ISP에서 SNI를 통한 감시, 검열을 시도할 경우 HTTP/2 Connection Coalescing[6]과 같이 임시적인 방책이 있을 수 있으나 표준화된 방어 방법은 아직 존재하지 않는다. Encrypted SNI 및 TLS 1.3 표준은 아직 제정 논의 중이며 또한 보편화되려면 많은 시간이 걸릴 것이다.

참고 링크

[1] http://www.mcst.go.kr/web/s_notice/press/pressView.jsp?pSeq=16672

[2] https://github.com/curl/curl/wiki/DNS-over-HTTPS#supported-in-browsers-and-clients

[3] https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers

[4] https://dnscrypt.info/public-servers/

[5] https://github.com/jedisct1/dnscrypt-proxy/releases

[6] https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/

Leave a comment

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다