25 KiB
title, icon, description
| title | icon | description |
|---|---|---|
| DNS 개요 | material/dns | DNS, 즉 도메인 네임 시스템은 '인터넷의 전화번호부'라고 할 수 있습니다. DNS가 있기 때문에 여러분은 브라우저에서 원하는 사이트를 찾아 연결할 수 있습니다. |
도메인 네임 시스템은 '인터넷의 전화번호부'라고 할 수 있습니다. DNS는 분산 서버 네트워크를 통해 도메인 이름을 IP 주소로 변환합니다. 브라우저 등의 서비스는 이를 이용해 인터넷 리소스를 로드할 수 있습니다.
DNS란 무엇인가요?
사이트를 방문하면 숫자로 구성된 주소가 반환됩니다. 예를 들어, privacyguides.org를 방문할 경우에는 192.98.54.105 주소가 반환됩니다.
DNS는 인터넷의 초창기부터 존재해 왔습니다. DNS 서버와 주고받는 DNS 요청은 일반적으로 암호화가 적용되어 있지 않습니다. 가정 환경에서는 DHCP를 통해 ISP로부터 서버를 제공받습니다.
암호화되지 않은 DNS 요청은 전송 도중에 쉽게 감시 및 변조될 수 있습니다. 일부 지역에서는 ISP가 기초적인 DNS 필터링을 수행하도록 명령받기도 합니다. 이 경우, ISP가 차단하고 있는 도메인의 IP 주소를 요청하면 서버가 응답하지 않거나, 목적지가 아닌 다른 IP 주소로 응답이 돌아옵니다. DNS 프로토콜은 암호화되지 않아서 ISP를 비롯한 모든 네트워크 사업자는 DPI를 통해 요청을 모니터링할 수 있습니다. 또한 ISP는 어떤 DNS 서버를 사용하든 공통된 특징을 이용해 요청을 차단하는 것도 가능합니다. 암호화되지 않은 DNS는 항상 53번 포트와 UDP를 사용합니다.
다음 내용은 암호화되지 않은 일반적인 DNS와 암호화가 적용된 DNS를 비교해 외부 관찰자가 볼 수 있는 것은 무엇이 있는지 증명하는 튜토리얼입니다.
암호화되지 않은 DNS
-
tshark를 이용하면 인터넷 패킷 흐름을 모니터링하고 기록할 수 있습니다(tshark는 Wireshark 프로젝트의 일부입니다). 다음 명령어는 명시된 규칙을 충족하는 패킷을 기록합니다.tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8 -
이후 Linux, macOS 등에서는
dig명령어를, Windows에서는nslookup명령어를 사용해 두 서버로 DNS 조회를 전송할 수 있습니다. 웹 브라우저 등의 소프트웨어는 암호화된 DNS를 사용하도록 설정된 경우가 아니라면 이러한 조회를 자동으로 수행합니다.=== "Linux, macOS"
``` dig +noall +answer privacyguides.org @1.1.1.1 dig +noall +answer privacyguides.org @8.8.8.8 ```=== "Windows"
``` nslookup privacyguides.org 1.1.1.1 nslookup privacyguides.org 8.8.8.8 ``` -
이제 결과를 분석합니다.
=== "Wireshark"
``` wireshark -r /tmp/dns.pcap ```=== "tshark"
``` tshark -r /tmp/dns.pcap ```
앞선 과정을 거쳐 Wireshark 명령어를 실행하면 상단 창에 여러 Frame이 표시되고, 하단 창에는 선택한 프레임에 대한 모든 데이터가 표시됩니다. 엔터프라이즈 필터링 및 모니터링 솔루션(정부에서 사용하는 솔루션 등을 말합니다)은 사람이 개입할 필요 없이 자동으로 이런 프로세스를 처리하고 집계하여 네트워크 관찰자에게 필요한 통계 데이터를 생성할 수 있습니다.
| No. | Time | Source | Destination | Protocol | Length | Info |
|---|---|---|---|---|---|---|
| 1 | 0.000000 | 192.0.2.1 | 1.1.1.1 | DNS | 104 | Standard query 0x58ba A privacyguides.org OPT |
| 2 | 0.293395 | 1.1.1.1 | 192.0.2.1 | DNS | 108 | Standard query response 0x58ba A privacyguides.org A 198.98.54.105 OPT |
| 3 | 1.682109 | 192.0.2.1 | 8.8.8.8 | DNS | 104 | Standard query 0xf1a9 A privacyguides.org OPT |
| 4 | 2.154698 | 8.8.8.8 | 192.0.2.1 | DNS | 108 | Standard query response 0xf1a9 A privacyguides.org A 198.98.54.105 OPT |
네트워크 관찰자는 이러한 패킷을 변조할 수 있습니다.
'암호화된 DNS'란 무엇인가요?
'암호화 DNS'는 여러 프로토콜이 존재합니다. 일반적인 종류는 다음과 같습니다.
DNSCrypt
DNSCrypt는 DNS 쿼리를 암호화하는 최초의 방법 중 하나였습니다. DNSCrypt는 443 포트에서 작동하며, TCP/UDP 전송 프로토콜 모두에서 작동합니다. DNSCrypt는 국제 인터넷 표준화 기구(IETF)에 제출되지 않았고
RFC 절차를 거치지 않았기 때문에, 일부 구현체를 제외하고는 널리 사용되지 않았습니다. 결과적으로, 보다 널리 사용되는 DNS over HTTPS로 대체되었습니다.
DOT(DNS over TLS)
DNS over TLS는 DNS 통신을 암호화하는 또 다른 방법으로, RFC 7858에 정의되어 있습니다. Android 9, iOS 14, Linux(systemd-resolved 237 버전)에서 처음으로 지원되었습니다. DoT는 복잡한 프로토콜인데다가 구현체마다 RFC 준수 여부가 다양하기 때문에, 최근 몇 년 동안은 업계 선호도가 DoT에서 DoH로 이동하고 있습니다. 또한, 853 포트를 전용으로 사용하기 때문에 제한적인 방화벽에 의해 쉽게 차단될 수 있다는 문제도 존재합니다.
DoH(DNS over HTTPS)
DNS over HTTPS는 RFC 8484에 정의되어 있으며, 쿼리를 HTTP/2 프로토콜에 패키징하여 HTTPS를 통해 보안을 제공합니다. Firefox 60, Chrome 83과 같은 웹 브라우저에서 처음으로 지원되었습니다.
DoH 네이티브 구현은 iOS 14, macOS 11, Microsoft Windows, Android 13(단, 기본 활성화가 아닙니다)부터 추가되었습니다. 일반 Linux 데스크톱의 경우, systemd 구현체가 아직 존재하지 않기 때문에 별도 소프트웨어를 설치해야 합니다.
외부 주체는 무엇을 볼 수 있나요?
다음 예시에서는 DoH 요청 시 실제로 어떤 일이 일어나는지 기록해보겠습니다.
-
먼저
tshark를 실행합니다.tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1" -
이후
curl를 이용해 요청을 생성합니다.curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org -
요청 후 CTRL + C를 눌러 패킷 캡처를 중지합니다.
-
Wireshark에서 결과를 분석합니다.
wireshark -r /tmp/dns_doh.pcap
연결 생성 및 TLS 핸드셰이크가 모든 암호화 연결에서 발생하는 것을 확인할 수 있습니다. 뒤따르는 'Application Data' 패킷을 살펴보면 요청했던 도메인이나 반환된 IP 주소가 포함되어 있지 않다는 것 또한 확인할 수 있습니다.
암호화 DNS를 사용하지 말아야 하는 이유는 무엇인가요?
인터넷 필터링(혹은 검열)이 존재하는 지역에서는 '차단된 정보에 접근하는 행위' 자체가 자신의 위협 모델에서 고려해야 할 어떠한 결과를 초래할 수도 있습니다. Privacy Guides는 이러한 목적으로 암호화 DNS를 사용하는 것은 추천드리지 않습니다. 대신 Tor나 VPN을 사용하세요. VPN을 사용하는 경우, 자신이 사용하는 VPN의 DNS 서버를 사용해야 합니다. VPN을 사용하는 순간부터 이미 자신의 모든 네트워크 활동을 VPN 업체에게 맡기고 있는 것이기 때문입니다.
일반적으로 우리가 무언가에 대한 DNS 조회를 할 때는 해당 리소스에 접근하고자 하는 의도가 있습니다. 다음은 암호화 DNS를 사용하더라도 여러분의 인터넷 탐색 활동이 노출될 수 있는 몇 가지 경우입니다.
IP 주소
인터넷 탐색 활동을 알아내는 가장 쉬운 방법은 해당 기기에서 접근하는 IP 주소를 확인하는 것입니다. 예를 들어, 어떤 관찰자가 privacyguides.org는 198.98.54.105에 존재함을 알고 있는 상태에서, 여러분의 기기가 198.98.54.105로 데이터를 요청한 것을 확인했다면, 여러분이 Privacy Guides를 방문했을 것으로 예상할 수 있습니다.
이 방식은 해당 IP 주소의 서버가 호스팅하고 있는 웹사이트의 개수가 적을 경우에만 유효합니다. 또한 공유 플랫폼(Github Pages, Cloudflare Pages, Netlify, WordPress, Blogger 등)에서 사이트가 호스팅되고 있는 경우에도 그다지 효과가 없습니다. 최신 인터넷 환경에서는 매우 일반적인 리버스 프록시 뒤에 호스팅되고 있는 경우에도 마찬가지로 그다지 효과가 없습니다.
SNI(Server Name Indication)
SNI(Server Name Indication, 서버 이름 표시)는 주로 하나의 IP 주소에서 여러 웹사이트를 호스팅하는 경우에 사용됩니다. Cloudflare 등의 서비스나, 그 외 서비스 거부 공격(DosS공격) 보호 서비스 등이 해당 예시입니다.
-
마찬가지로
tshark로 캡처를 시작합니다. 지나치게 많은 패킷이 캡처되지 않도록 Privacy Guides의 IP 주소 필터를 추가합시다.tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105 -
이제 https://privacyguides.org를 방문합니다.
-
사이트를 방문한 이후에는 CTRL + C로 패킷 캡처를 중지합니다.
-
이제 결과를 분석합시다.
wireshark -r /tmp/pg.pcap
연결이 설정이 이루어지고 Privacy Guides 사이트에 대한 TLS 핸드셰이크 과정을 확인할 수 있습니다. 프레임 5 주변에서 "Client Hello"를 확인할 수 있습니다.
-
각 필드 옆의 삼각형 ▸을 눌러 펼칩니다.
▸ Transport Layer Security ▸ TLSv1.3 Record Layer: Handshake Protocol: Client Hello ▸ Handshake Protocol: Client Hello ▸ Extension: server_name (len=22) ▸ Server Name Indication extension -
방문 중인 사이트를 나타내는 SNI 값을 확인할 수 있습니다.
tshark명령어로 SNI 값을 포함한 모든 패킷 값을 직접 확인 가능합니다.tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
즉, '암호화 DNS'를 사용하더라도 도메인은 SNI를 통해 노출될 가능성이 높습니다. TLS 1.3 프로토콜에는 이런 방식의 유출을 방지하는 Encrypted Client Hello 기능이 존재합니다.
하지만 Encrypted Client Hello 또한 여러 정부(특히 중국, 러시아)에서 차단을 시작했거나, 차단을 시도하고 있습니다. 최근 러시아는 HTTP/3 표준을 사용하는 해외 사이트를 차단하기 시작했습니다. HTTP/3의 일부인 QUIC 프로토콜에서는 ClientHello 암호화가 필수적이기 때문입니다.
OCSP(온라인 인증서 상태 프로토콜)
OCSP를 통해 인터넷 탐색 활동이 노출될 가능성도 있습니다. 여러분이 HTTPS 웹사이트를 방문할 때, 브라우저는 해당 웹사이트의 인증서가 만료되었는지 확인합니다. 이 과정은 HTTP 프로토콜을 사용해 이루어집니다. 다시 말해, 암호화가 적용되지 않습니다.
OCSP 요청에는 고유한 인증서 일련번호가 포함되어 있습니다. 이는 인증서 상태를 확인하는 과정에서 'OCSP 응답자(Responder)'에게 전송됩니다.
openssl 명령어로 브라우저의 동작을 시뮬레이션할 수 있습니다.
-
서버 인증서를 가져오고
sed를 이용해 중요한 부분만 파일에 기록합니다.openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 | sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert -
중간 인증서(Intermediate Certificate)를 받습니다. 인증 기관(CA)은 일반적으로 인증서에 직접 서명하지 않고 '중간 인증서'라고 불리는 것을 사용합니다.
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 | sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert -
pg_and_intermediate.cert의 첫 번째 인증서는 1단계에서의 서버에 대한 인증서입니다.sed명령어를 다시 사용해 END가 처음 등장하는 부분까지 제거합니다.sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \ /tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert -
서버 인증서에 대한 OCSP 응답자를 얻어냅니다.
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
인증서에서 Lets Encrypt 인증서 응답자를 확인할 수 있습니다. 인증서의 모든 세부 정보를 확인하려면 다음 명령어를 사용합니다.
```bash
openssl x509 -text -noout -in /tmp/pg_server.cert
```
-
패킷 캡처를 시작합니다.
tshark -w /tmp/pg_ocsp.pcap -f "tcp port http" -
OCSP 요청을 생성합니다.
openssl ocsp -issuer /tmp/intermediate_chain.cert \ -cert /tmp/pg_server.cert \ -text \ -url http://r3.o.lencr.org -
캡처를 엽니다.
wireshark -r /tmp/pg_ocsp.pcap
'OCSP' 프로토콜에서 'Request', 'Response'라는 두 패킷을 확인할 수 있습니다. 'Request'에서는 각 필드 옆의 삼각형 ▸을 눌러 일련번호(Serial Number)를 확인할 수 있습니다.
```bash
▸ Online Certificate Status Protocol
▸ tbsRequest
▸ requestList: 1 item
▸ Request
▸ reqCert
serialNumber
```
'Response'에서도 마찬가지로 일련번호를 확인할 수 있습니다.
```bash
▸ Online Certificate Status Protocol
▸ responseBytes
▸ BasicOCSPResponse
▸ tbsResponseData
▸ responses: 1 item
▸ SingleResponse
▸ certID
serialNumber
```
-
혹은
tshark를 이용해 패킷을 일련번호로 필터링합니다.tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
네트워크 관찰자가 공개적으로 사용할 수 있는 공개 인증서를 가지고 있는 경우, 일련번호를 해당 인증서와 대조할 수 있으므로 여러분이 어떤 사이트를 방문하는지 알아낼 수 있습니다. 이 과정은 자동화될 수 있으며, 일련번호를 IP 주소와 연관시킬 수 있습니다. 인증서 투명성 로그에서 일련번호를 확인하는 것 또한 가능합니다.
"제가 암호화 DNS를 사용해야 할까요?"
Privacy Guides는 여러분이 언제 암호화 DNS를 사용해야 할지 판단할 수 있도록 플로우차트로 정리해 보았습니다.
graph TB
Start[시작] --> anonymous{익명성을<br>원하시나요?}
anonymous--> | 예 | tor(Tor를 사용하세요)
anonymous --> | 아니요 | censorship{검열 회피가<br>목적인가요?}
censorship --> | 예 | vpnOrTor(VPN이나 Tor를<br>사용하세요)
censorship --> | 아니요 | privacy{ISP로부터의<br>프라이버시가<br>목적인가요?}
privacy --> | 예 | vpnOrTor
privacy --> | 아니요 | obnoxious{"ISP의 간섭이<br>성가신가요?<br>(강제 리다이렉트 등)"}
obnoxious --> | 예 | encryptedDNS(제3자 암호화 DNS를<br>사용하세요)
obnoxious --> | 아니요 | ispDNS{ISP에서<br>암호화 DNS를<br>지원하나요?}
ispDNS --> | 예 | useISP(ISP 암호화 DNS를<br>사용하세요)
ispDNS --> | 아니요 | nothing(아무 것도<br>할 필요 없습니다)
제3자 서버를 사용하는 암호화 DNS는 '이를 사용함으로써 아무런 문제가 발생하지 않을 것이라고 확신할 수 있을 때' ISP의 기본적인 리디렉션 및 DNS 차단을 우회하는 용도로만 사용하거나, 기초적인 DNS 필터링 서비스를 필요로 할 때만 사용해야 합니다.
권장 DNS 서버 목록{.md-button}
DNSSEC이란 무엇인가요?
DNSSEC(Domain Name System Security Extensions)는 도메인 이름 조회에 대한 응답을 인증하는 DNS 기능입니다. 이 기능은 프라이버시 보호와는 별 관련이 없지만, 공격자가 DNS 요청 응답을 변조하거나 오염시키는 것을 방지합니다.
DNSSEC은 데이터 유효성을 보장하기 위해 데이터에 디지털 서명을 수행합니다. 안전한 조회 과정을 보장하기 위해, 디지털 서명은 DNS 조회 과정의 모든 영역에서 이루어집니다. 결과적으로, 모든 DNS 응답을 신뢰할 수 있습니다.
DNSSEC 서명 과정은 사람이 펜으로 법적 문서에 서명하는 과정과 유사합니다. 다른 사람이 따라 만들 수 없는 고유한 서명으로 서명하고, 법조인은 해당 서명을 보고 문서의 서명이 위조되지 않았음을 확인합니다. 마찬가지로 디지털 서명은 데이터가 변조되지 않았음을 확인합니다.
DNSSEC은 DNS의 모든 계층에 걸쳐 계층적(Hierarchical) 디지털 서명 정책을 구현합니다. 예를 들어 privacyguides.org를 조회하는 경우, 루트 DNS 서버는 자신의 키로 서명해 .org 네임 서버에게 제공하고, .org 네임 서버 또한 자신의 키로 서명해 privacyguides.org의 권한 있는 서버에 제공합니다.
Google의 DNS Security Extensions (DNSSEC) 개요와 Cloudflare의 DNSSEC: An Introduction를 각색하였으며, 두 글은 모두 CC BY 4.0 라이선스를 따릅니다.
QNAME 최소화란 무엇인가요?
QNAME은 '정규화된 이름(Qualified Name)'입니다(예시: discuss.privacyguides.net). In the past, when resolving a domain name your DNS resolver would ask every server in the chain to provide any information it has about your full query. In this example below, your request to find the IP address for discuss.privacyguides.net gets asked of every DNS server provider:
| Server | 질문 | 응답 |
|---|---|---|
| 루트 서버 | discuss.privacyguides.net의 IP는 무엇인가요? | I don't know, ask .net's server... |
| .net 서버 | discuss.privacyguides.net의 IP는 무엇인가요? | I don't know, ask Privacy Guides' server... |
| Privacy Guides 서버 | discuss.privacyguides.net의 IP는 무엇인가요? | 5.161.195.190! |
With "QNAME minimization," your DNS resolver now only asks for just enough information to find the next server in the chain. In this example, the root server is only asked for enough information to find the appropriate nameserver for the .net TLD, and so on, without ever knowing the full domain you're trying to visit:
| Server | 질문 | 응답 |
|---|---|---|
| 루트 서버 | What's the nameserver for .net? | Provides .net's server |
| .net 서버 | What's the nameserver for privacyguides.net? | Provides Privacy Guides' server |
| Privacy Guides 서버 | What's the nameserver for discuss.privacyguides.net? | This server! |
| Privacy Guides 서버 | discuss.privacyguides.net의 IP는 무엇인가요? | 5.161.195.190 |
While this process can be slightly more inefficient, in this example neither the central root nameservers nor the TLD's nameservers ever receive information about your full query, thus reducing the amount of information being transmitted about your browsing habits. 세부 기술 설명은 RFC 7816에 정의되어 있습니다.
ECS(EDNS 클라이언트 서브넷)란 무엇인가요?
EDNS 클라이언트 서브넷이란, DNS 쿼리를 생성하는 호스트나 클라이언트의 서브넷을 Recursive DNS 리졸버가 지정할 수 있는 방식입니다.
ECS는 동영상 스트리밍이나 JavaScript 웹 앱 서비스에 때 자주 쓰이는 콘텐츠 전송 네트워크(CDN)처럼 클라이언트와 가까운 서버의 응답을 제공하여 데이터 전송 속도를 높이는 기술입니다.
단, ECS는 DNS 서버에 클라이언트의 위치에 관한 일부 정보를 알려주기 때문에 프라이버시 면에서 불이익이 존재합니다.