네트워크 / 보안

'DNSSEC부터 DoH·DoT까지' DNS 트래픽 암호화의 이해

Ax Sharma | CSO 2021.04.01
인터넷 백본인 DNS(Domain Name System) 프로토콜은 그동안 여러 차례 개선됐다. 예를 들어 최초 DNS 사양에는 엄격한 보호 수단이 없었지만, 이후 카민스키(Kaminsky) 버그와 같은 보안상 취약점이 발견되면서 2010년 DNSSEC(Domain Name System Security Extensions)이 탄생했다. 
 
ⓒ Getty Images Bank

DNSSEC은 디지털 서명 기반의 암호화로 보안을 강화한다. 전 세계 DNS 클라이언트는 이를 이용해 DNS 응답이 정상적인 DNS 서버에서 왔으며 전송 과정에서 변조되지 않았음을 확인한다.

그런데 이후 DNS 오버 HTTPS(DNS over HTTPS, DoH)와 DNS 오버 TLS(DNS over TLS, DoT)가 등장했다. DNSSEC이 충분한 보안을 제공한다면 이들이 왜 필요한 것일까.

이유는 DNSSEC가 DNS 응답의 진정성과 데이터 무결성을 보장하지만 개인정보는 보호하지 않기 때문이다. 반면 DoH와 DoT) 같은 프로토콜은 종단간 암호화를 제공하므로 데이터의 기밀성이 보장된다. 즉, DNS 트래픽도 HTTPS 사이트 간의 웹 트래픽과 같은 종단간 암호화의 이점을 얻게 된다.
 

DoH란? 

DNS는 전송 제어 프로토콜(Transmission Control Protocol, TCP)에서 사용할 수도 있지만 기본적으로 DNS 프로토콜은 전송 계층 프로토콜인 사용자 데이터그램 프로토콜(User Datagram Protocol, UDP)에서 동작한다.

DoH는 더 빠른 UDP가 아닌 HTTPS를 통해 암호화된 DNS 메시지를 전송한다. HTTPS는 전송 계층 보안(Transport Layer Security, TLS)에서 실행되는 HTTP 프로토콜이므로 DoH는 사실상 DNS 오버 HTTP 오버 TLS(DNS over HTTP over TLS)라고 할 수 있다. 

DoH에서 DNS 질의와 DNS 응답은 모두 HTTPS를 통해 전송되며 포트 443을 사용하므로 다른 HTTPS 웹 트래픽과 거의 구분할 수 없다. 예를 들어 지금 바로 웹 브라우저에서 구글 DoH 서비스를 사용해서 CSOOnline.com 도메인 해석(resolve)을 시도해 보자.

브라우저에 HTTPS URL을 입력해 HTTPS를 통해 도메인 이름을 해석하는 방식은 SSL/TLS를 사용하는 일반 웹사이트를 방문할 때와 차이가 없다는 것을 알 수 있다. 즉 구글이 반환하는 DNS 응답은 CSO의 서버 IP 주소(A 레코드)로, 모두 JSON 형식으로 깔끔하게 포장돼 있다. 
 
구글 DoH 서비스는 JSON 포맷으로 DNS 응답을 반환한다. © AX SHARMA

구글 DoH 서비스를 사용한다는 사실이 네트워크 관리자에게 알려질 수 있지만,  사용자와 구글 DoH 사이에 기업 중간자(man-in-the-middle, MitM) 프록시가 없다고 가정하면 사용자가 조회하고자 하는 도메인(CSO 온라인)이 무엇인지, 또는 이 DNS 질의에 대한 응답(JSON 결과)이 무엇인지 누구도 알아낼 수 없다.

결국 DoH를 사용하면 개인정보(데이터 기밀성) 보호와 수신된 정보의 무결성(DNS 응답이 전송 중 변조되지 않음)이 보장된다.  

단, 종단간 암호화 채널을 통해 DNS를 전송하는 방식에는 문제의 소지도 있다. 예를 들어 공격자가 DoH 서비스를 악용해 악성 트래픽을 숨긴 사례가 있다. 

공격자는 구글의 DoH 또는 아무 DoH 제공업체를 통해 악성 도메인을 해석할 수 있다. 반환된 암호화된 응답에는 공격자가 제어하는 도메인의 TXT 레코드와 함께 암호화된 악성 페이로드가 포함되고, 악성코드가 이 페이로드를 파싱할 수 있다.

이것이 기본적으로 위협 행위자가 지휘통제(C2) 활동을 용이하게 하기 위해 보안 DNS 프로토콜을 악용하는 방법이다. DoH 제공업체는 합법적인 비즈니스 사용 사례가 있으므로 기업 네트워크와 DoH 제공업체 간의 인바운드 또는 아웃바운드 트래픽을 단순히 차단하기 어렵다.
 

DoT란? 

DoT는 애플리케이션 계층에 상주하는 HTTPS가 아닌 전송 계층에서 TLS 프로토콜을 통해 DNS 질의를 암호화한다. DoT는 DoH와 달리 그 사이의 계층 하나, 즉 애플리케이션 수준 HTTPS를 생략한다. 

기본적으로 DoT는 DNS UDP 요청과 응답을 TLS를 통해 암호화하며 메시지가 전송 과정에서 변경되지 않도록 보장한다. DoT는 HTTPS(포트 443) 또는 일반 DNS(포트 53)와는 다른 포트 853을 사용한다. DNS 클라이언트와 리졸버 간의 통신이 TLS를 통해 이뤄지므로 DoT 트래픽도 DoH와 마찬가지로 종단간 암호화의 이점을 얻게 된다. 
 

어느 DNS 프로토콜이 더 좋을까

DoH와 DoT 중 무엇이 나은지는 논란거리다. 네트워크 관리자라면 DNS 질의 모니터링 측면에서 더 높은 유연성을 제공하는 DoT 쪽으로 기울 수 있다. 특히 네트워크에서 악성 DNS 트래픽과 침해 지표(IOC)를 차단하려는 보안 전문가라면 DoT가 유용하다. 

DoH의 경우 사용자의 DNS 질의가 다른 HTTPS 트래픽과 섞이므로 최종 사용자의 개인정보 보호가 더 강화되는 반면 네트워크 관리자는 해석되는 도메인과 반환되는 DNS 응답을 확인할 수 없다. 즉, 네트워크 관리자 입장에서는 정상적인 비즈니스 통신에 영향을 미치지 않으면서 DoH를 차단하기가 훨씬 더 어렵다. 

예를 들어 DoT 차단을 위해 기업 방화벽을 구성해 포트 853을 통해 이동하는 트래픽을 일률적으로 필터링하는 정책을 추가하기는 쉬운 반면 포트 443(DoH) 필터링은 현실적으로 사용하기가 어렵다. 대부분의 정상적인 웹 트래픽도 차단되기 때문이다. 

또 하나 참고할 점은 DoH는 애플리케이션 계층에 위치하는 HTTPS를 사용하는 반면 DoT는 전송 계층에 위치하므로 약간 더 가볍다는 것이다. 관여하는 계층의 수가 적으므로 DoT 패킷의 크기가 더 작고, 이는 DoH와 비교할 때 약간의 성능 우위(다시 말해 더 낮은 지연)로 이어질 수 있다.

한편 선택할 수 있는 것은 DoT, DoH 외에 또 있다. 클라우드플레어(Cloudflare)와 같은 네트워크 인프라 기업은 DNS 오버 트위터(DNS over Twitter), DNS 오버 토르(DNS over Tor), DNS 오버 텔레그램(DNS over Telegram), DNS 오버 이메일 등 새로운 프로토콜도 포함하도록 DNS를 확장하고 있다. 

실제로 클라우드플레어는 고객 사이트 방문자가 토르 네트워크를 사용하도록 허용하는 어니언(Onion) 서비스를 제공한다. 클라우드플레어의 리졸버 1.1.1.1은 DoH와 DoT를 모두 지원하며 어니언 서비스를 통해 제공된다.

클라우드플레어의 연구 책임자인 닉 설리반은 “우리는 이것을 DNS 오버 토르라고 한다. 또한 @1111Resolver를 대상으로 한 특정 형식의 트윗을 수신하고 이를 DNS 질의로 변환하고 1.1.1.1로 질의를 해석해 결과를 트윗으로 보내는 트위터봇도 운영 중이다”라고 말했다. 

새롭게 고안된 프로토콜의 상당수는 HTTPS 또는 SOCKS(토르) 같은 암호화된 채널을 사용하며, 최종 사용자에게 더 많은 선택권을 제공하지만 트래픽 필터링 측면에서는 보안 전문가에게 더 큰 어려움이 될 수 있다.

예를 들어 세밀한 보조 대책 없이 DNS 오버 트위터를 차단하면 트위터 전체가 차단될 수 있다. 엔터프라이즈 MitM 프록시와 같은 보조 대책을 사용할 경우 기밀성과 사용자 개인정보 보호 측면에서 DoH가 제공하는 많은 보호 기능이 무효화될 수 있다.

결국 DoT든 DoH든 DNS 프로토콜 사용은 기업의 필요에 따라 결정된다. 사용자 개인정보 보호와 적절한 네트워크 모니터링 간의 타협 기준을 어디에 두느냐도 중요한 기준이다. editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.