암호화 유지, 안전하게 유지: ESNI, DoH 및 DoT 작업

인터넷에서 개인 정보를 보호하기 위한 최신 개발에는 암호화된 TLS 서버 이름 표시(ESNI) 및 HTTPS를 통한 DNS(DoH) 형식의 암호화된 DNS가 포함되며, 둘 다 데이터 수집가에서 매우 논쟁의 여지가 있는 것으로 간주됩니다.

그래서 여기에 그들이 존재하는 이유, 그것이 무엇인지에 대한 세부 사항, 작동 방식 이면의 기술에 대해 간략히 살펴보겠습니다.

DNS가 올바르게 작동해야 함

분할 터널 VPN(가상 사설망) 연결, WPAD(웹 프록시 자동 검색) 프로토콜, mDNS(제로 구성 멀티캐스트 DNS), RBL(실시간 블랙리스트) 및 기타 널리 배포된 기술은 DNS가 연결되지 않으면 중단됩니다. t 올바르게 작동합니다.

이익과 명예를 위해 인터넷을 깨다

2003년으로 거슬러 올라가면 인터넷 사용자는 .com 최상위 도메인(TLD)을 실행한 회사가 NXDOMAIN 응답 발행을 중단하기로 결정했을 때 전 세계적으로 DNS의 중요성에 대해 배웠습니다. 대신 더 많은 광고를 게재하고 더 많은 도메인을 판매하여 궁극적으로 더 많은 수익을 창출하기 위해 존재하지 않는 도메인을 사칭 했습니다. 예상치 못한 연쇄 효과는 공개 토론과 ICANN의 SSAC(보안 및 안정성 자문 위원회)의 끔찍한 보고서로 이어졌습니다. 이 프로젝트는 실제로 중단되었지만 기술적인 관점에서 취약점은 지속되었습니다.

2008년 후반에 가장 큰 ISP 중 일부가 문자 그대로 모든 웹사이트에 대해 교차 사이트 스크립팅 공격을 위한 다양한 방법을 도입하면서 수익을 위해 DNS를 조작하려는 또 다른 시도가 공개적으로 제기되었습니다. 취약점의 특성으로 인해 사설망에서 호스팅되고 인터넷에서 액세스할 수 없는 웹사이트도 악용될 수 있습니다.

발견된 문제는 핵심 인터넷 프로토콜에 있는 것이 아니라 특정 DNS 기능의 부적절한 수익 창출로 인해 악화된 문제입니다.

Paul Vixie, 인터넷 시스템 컨소시엄(ISC)

프로토콜 자체가 실제로 문제의 원인이 아닌 것은 사실이지만 이러한 프로토콜이 악의적인 행위자가 시스템을 악용하는 것을 방지하지 못하는 것도 사실입니다. 따라서 기술적인 측면에서 취약점이 지속되었습니다.

감시 및 검열을 위한 인터넷 차단

2016년에는 이란의 ISP가 DNS를 조작하는 것이 관찰되었습니다. 이번에는 광고를 삽입하는 대신 인터넷 상위 10,000개 도메인 중 139개의 이메일 서버에 대한 액세스를 차단했습니다. 이것이 중국의 세계적으로 유명한 검열과 유사한 이러한 특정 도메인에 대한 의도적인 서비스 거부 정책인지 아니면 DNS 쿼리를 가로채는 시스템의 잘못된 기술 구현의 예일 뿐인지는 분명하지 않습니다.

DNS가 가로채는 이유를 모르는 것이 중요합니다. 전면적인 감시 및 검열에 대한 도덕적, 법적 문제를 제쳐두더라도 이를 수행하는 데 사용되는 기술은 본질적으로 표준을 준수하지 않으며 DNS를 방해할 수 있습니다. 일상적이고 합리적이며 합법적인 인터넷 사용.

그러나 기술적인 관점에서 취약점은 지속되었습니다.

사악한 목적을 위한 인터넷 차단

물론, 자신들의 수단으로 인터넷 트래픽을 가로채려고 하는 것은 영리 기관과 정부만이 아닙니다. 일반적으로 사용자 데이터를 훔치거나 사용자를 속여 중요한 액세스 자격 증명을 노출시키려는 목적으로 연결을 하이재킹하려는 범죄자의 예가 많이 있습니다. 가장 두드러지게 DNS 캐시 중독은 사용자를 피싱 사이트로 안내하고, 랜섬웨어를 배포하고, 봇넷을 배포하고, 특정 웹사이트에 대한 서비스를 거부하는 데 사용되었습니다.

누가 누구에게 연결하는지 TLS 누출

TLS(전송 계층 보안)는 우리 모두가 매일 사용하는 HTTP의 보안 버전인 HTTPS 이면의 기술입니다. TLS 연결을 설정하려면 여러 단계가 필요하며 이 동안 서버는 인증서를 제시하여 자신의 신원을 증명하고 새 암호화 키를 교환합니다.

인증서의 일부가 비대칭 공개 암호화 키이기 때문에 서버가 인증서를 사용하여 ID를 증명하도록 하는 것은 매우 중요한 단계입니다.

클라이언트가 이 키를 사용하여 메시지를 보낼 때 연결된 개인 키를 소유한 서버만 메시지를 읽을 수 있습니다. 결과적으로 연결을 가로채거나 듣는 사람은 모두 잠겨 콘텐츠를 읽을 수 없습니다.

그러나 그 초기 교환은 여전히 ​​암호화 없이 일반 상태로 수행되며, 이는 관찰자가 항상 서버의 ID를 알고 있음을 의미합니다.

도메인 프론팅

몇 가지 검열 방지 유형 도구는 도메인 프론팅으로 알려진 기술을 사용하여 일정 기간 동안 TLS에서 이 누출을 해결했습니다. 이것은 HTTPS 연결이 설정되면 대부분의 대규모 호스팅 공급자가 각 HTTP 요청에 제공된 호스트 이름이 TLS 핸드셰이크에 사용된 호스트 이름과 일치하는지 확인하지 않는다는 사실을 이용합니다. 프라이버시 툴 측면에서는 숨겨진 사이트와 은밀하게 소통할 수 있는 유용한 기능으로 여겨졌다. 호스팅 제공업체 및 데이터 수집기의 경우 이는 사양이 구현되는 방식을 남용하는 것으로 간주되었습니다.

이것은 그 자체로 취약점이며 AWS를 포함한 여러 주요 호스팅 제공업체에서 수정했습니다.

표준을 변경하여 문제 해결: 암호화된 SNI(ESNI)

ESNI의 이면에 있는 아이디어는 초기 Client Hello 메시지를 포함하여 모든 메시지를 암호화하여 TLS가 데이터 누출을 방지하는 것입니다. 이것은 서버가 제시하는 서버 인증서에 대해 모든 관찰자를 완전히 어둠 속에 빠뜨립니다.

이렇게 하려면 연결하기 전에 클라이언트에 암호화 키가 필요합니다. 따라서 ESNI를 사용하려면 DNS의 SRV 레코드에 특정 ESNI 암호화 키 세트가 있어야 합니다.

이에 대한 정확한 세부 사항은 여전히 ​​유동적이지만 사양이 아직 확정되지 않았기 때문입니다. 그럼에도 불구하고 ESNI의 구현은 이미 Mozilla Firefox 및 Cloudflare에 의해 생산에 투입되었습니다.

DNS 보안 및 암호화

ESNI 키가 가로채지 않고 전달되려면 DNS 변조로부터 보호하는 것이 중요합니다.

1993년부터 인터넷 커뮤니티는 DNS를 보호하기 위해 노력해 왔습니다. IETF는 초기 문제 해결 회의에서 다음과 같이 논의했다고 언급합니다.

1. 승인되지 않은 당사자에 대한 DNS 데이터 공개로부터 보호
2. 데이터 무결성 보장
3. 데이터 출처 인증

이러한 회의를 통해 1997년 DNSSEC(Domain Name System Security Extensions) 표준이 탄생했습니다. 설계 팀이 명시적으로 범위를 벗어나는 모든 데이터 공개 위협을 배제하기로 명시적인 결정을 내렸기 때문에 이 표준은 이러한 우려 사항 중 3가지 중 2가지를 해결하기로 결정했습니다.

따라서 DNSSEC는 사용자가 DNS 쿼리에 대한 응답이 도메인 소유자가 의도한 대로라고 신뢰할 수 있음을 의미합니다. ESNI의 맥락에서 이것은 우리가 수신하는 키가 변조되지 않았음을 알고 있으며 고맙게도 위에서 언급한 많은 취약점이 DNSSEC가 사용 중일 때 사라집니다. 그러나 개인 정보를 보장하지 않으므로 감시 및 검열 시스템으로 인해 발생하는 문제에 여전히 취약합니다.

불행히도 "안전하지 않은 DNS"와 완벽하게 역호환되고 올바르게 구현하기가 매우 어렵기 때문에 DNSSEC의 채택은 매우 낮습니다. 많은 도메인 소유자가 구성을 시도하는 도중에 포기하고 있습니다. 이는 실제 환경에서 볼 수 있는 수많은 유효하지 않은 설정 구성에서 알 수 있습니다.

HTTPS를 통한 DNS(DoH)

감시자가 방문하려는 사이트 사용자를 알지 못하는 상태에서 ESNI 키를 전달하려면 DNS 도청으로부터 보호하는 것이 중요합니다. 따라서 DoH와 같은 암호화된 DNS 가 좋은 것이라고 말하는 것은 매우 논리적이고 이해할 수 있습니다. 그러나 오늘날과 같이 DNS는 암호화되지 않습니다.

Mozilla, Google, APNIC, Cloudflare, Microsoft 등이 이를 변경하려는 움직임이 있습니다.

이상적인 암호화 사용자 경험

위의 기술을 활용하려는 사용자는 암호화 작업에 대한 실용적인 UX 세부 정보와 관련하여 요구 사항 목록이 다소 길 수 있습니다. 아마도 그들은 다음과 같은 것을 피하고 싶어할 것입니다.

• 특정 DNS 서비스 제공업체를 사용하도록 강요받거나(아무리 좋은 서비스라도) 선택 사항이 보이지 않거나 찾기 어려운 경우
• DNS를 다르게 처리하는 기기의 각 앱(예: Firefox는 Safari가 찾을 수 없는 항목을 찾을 수 있음)
• 자체 보안 DNS 구현을 자체적으로 생성해야 하는 기기의 모든 앱
• DNS를 여러 번 수동으로 구성해야 함
• 개인 정보 보호 및 보안을 선택해야 함
• 사용자 동의 없이 안전하지 않은 작동으로 되돌아가는 앱

프라이버시에 민감한 사용자는 대신 다음을 원할 것입니다.

• 누군가의 부당한 감시로부터 개인 정보 보호
• 동의하지 않은 타겟 광고로부터 보호
• 자신이 게시한 콘텐츠(예: 개인 웹사이트)가 다른 시청자에게 전달되는 도중에 변경되거나 조작되지 않도록 보호
• 자신이 게시한 콘텐츠의 시청자가 단순히 액세스하는 데 문제가 발생하지 않도록 보장
• 자체 네트워크에서 DNS를 제어하는 ​​옵션을 계속 유지하려면(때로는 분할-수평 DNS가 내부 리소스 범위를 내부 사용자로 유지하는 데 적합하기 때문)
• DNS 수준(예: Quad9, CleanBrowsing 및 OpenDNS Family Shield)에서 필터링을 선택하거나 최소한 선택 해제하는 기능
• 쉽고 간편한 구성(예: DHCP)
• 암호화 없이 DNS 사용에 대한 동의를 요청하려면
• 브라우저 트래픽뿐만 아니라 모든 유형의 트래픽(예: 이메일, Slack, VoIP, SSH, VPN 등)에 대한 보호

현재 암호화 노력

위의 목표를 가진 사용자에게는 어떤 옵션이 있습니까?

Mozilla의 솔루션은 시작이지만 이상적이지는 않습니다. 그들은 단지 Firefox를 보호하고 있습니다. 기본값은 제공자(Cloudflare) 선택을 위해 OS 설정을 무시하고, 그렇게 말하지 않고 자동으로 안전하지 않은 상태로 돌아갑니다(암호화된 DNS가 차단되는 경우 등).

Google의 솔루션이 더 나은 접근 방식입니다. 모든 앱에 적용되는 Android 9 이상을 보호하고 있습니다. (Chrome OS에 대한 계획은 확실하지 않지만 작업 중인 것으로 생각됩니다.) 또한 모든 플랫폼에서 Chrome을 보호하고 있지만 호스트 플랫폼이 보안을 지원하는 공급자를 사용하도록 구성된 경우에만 보안을 트리거합니다. 이것은 사용자 선택의 관점에서 좋지만, 자동으로 안전하지 않은 상태로 돌아가므로 이상적이지 않습니다.

다른 모든 주요 브라우저도 지원을 구현하고 있습니다.

사용자에게 이상적인 상황에서 더 넓은 범위의 소프트웨어 및 OS 개발자 커뮤니티는 다음을 수행합니다.

1. 애플리케이션 수준에서 새로운 DNS 보안 기능 구현 중단
2. OS 수준에서 구현 시작
3. OS 수준 구성을 존중하거나 사용자 동의를 얻습니다.

OS 수준에서 암호화된 DNS를 구현하면 현재 DNS 확인자에 대해 사용하는 것과 동일한 분산 모델을 계속 따를 수 있습니다. 자체 네트워크에서 자체 DNS 서버를 실행하고 해당 리졸버를 안전하게 만들 수 있다는 것은 중앙 집중식 공급자를 사용해야 하는 것처럼 계속 옵션이 되는 것이 합리적입니다.

Linux 및 BSD에는 이미 다양한 옵션을 사용할 수 있는 이 기능이 있습니다. 불행히도 내가 아는 한 어떤 배포판도 기본적으로 활성화하지 않습니다. glibc에 바로 연결될 무언가를 원한다면 nss-tls를 확인하십시오.

Android 9+에서 Google의 DNS-over-TLS 구현도 이미 이 작업을 수행합니다. 암호화 지원을 위해 DNS 서버를 테스트하여 작동합니다. 그것이 있으면 그것을 사용할 것입니다. 그렇지 않은 경우 Chrome과 마찬가지로 동의를 요청하지 않고 안전하지 않은 방식으로 계속됩니다.

대부분의 네트워크는 암호화를 지원하지 않는 DNS 서버를 사용하도록 구성되어 있으므로 Android에 내장된 솔루션은 아직 대부분의 사용자를 위해 아무 것도 변경하지 않습니다. 탈중앙화에서 암호화를 지원하지 않는 경우 중앙 집중식 암호화 DNS로 대체하도록 제안하는 것이 더 나을 수도 있습니다.

Apple 및 Microsoft 풍미 장치의 경우 암호화된 DNS에 대한 지원은 이 글을 쓰는 시점에서 아직 공식적으로 도착하지 않았습니다. Microsoft가 2019년 11월에 암호화된 DNS를 지원하겠다는 의사를 발표함에 따라 Apple도 곧 따를 것입니다.

암호화된 DNS 해결 방법

로컬에서 실행할 수 있는 프록시 형태의 몇 가지 해결 방법이 있습니다. 이를 통해 사용자의 컴퓨터는 암호화되지 않은 DNS를 자신에게 말하고 암호화된 DNS를 사용하도록 구성된 공급자에게 말합니다. 이것은 이상적인 솔루션은 아니지만 해결 방법이 진행됨에 따라 적절합니다.

이 기사를 작성하게 된 영감은 DNSCrypt 프록시로, 매우 안정적이고 다양한 기능을 제공하며 크로스 플랫폼입니다. 이전 DNSCrypt 프로토콜과 최신 DoT(DNS over TLS) 및 DNS over HTTPS(DoH) 프로토콜을 지원합니다.

Windows 사용자의 경우 기능이 완전하고 사용하기 쉬운 Simple DNSCrypt라는 설치 프로그램 및 GUI가 있습니다.

권장하지만 아직 세상이 준비되지 않았으며 때때로 비활성화해야 할 수도 있습니다(예: 즐겨찾는 카페 또는 LAN에서 캡티브 포털을 사용해야 하는 경우). 파티).

다른 옵션

또한 암호화된 DNS를 지원하고 크로스 플랫폼(Windows, MacOS, Linux on ARM/Raspberry Pi)이며 매끄러운 웹 인터페이스를 제공하는 Technitium DNS 서버가 있습니다. 이 문제와 관련된 솔루션이라기보다 만능 도구에 가깝기 때문에 "기타" 아래에 있습니다. (집에서 Raspberry Pi DNS 서버를 실행하고 싶다면 좋은 선택일 것입니다. 아래 댓글에서 사용해 본 사람들의 피드백을 듣고 싶습니다.)

Android 또는 iOS(iPhone, iPad 등) 장치의 경우 Cloudflare 암호화 DNS 서비스를 통해 모든 DNS 쿼리를 강제 실행하는 1.1.1.1 앱도 있습니다. Intra와 같은 더 유연한 앱도 있다고 들었지만 아직 테스트할 시간이 없습니다.

물론 Firefox와 Chrome 모두에서 암호화된 DNS를 활성화할 수도 있습니다. 위에서 설명한 모든 주의 사항을 염두에 두십시오.

DNS 안정성: 작업 번호 1

인터넷 개인 정보 보호 기술에 대해 많은 논란이 있습니다. 그러나 보안 및 개인 정보 보호 조치를 구현할 때 문제의 기술은 주로 비밀 유지에 관한 것이 아닙니다. 신뢰성을 보장하고 다른 사람의 행동에도 불구하고 기술이 계속해서 올바르게 작동하도록 보장하는 것입니다. 그러나 개인 정보 보호 장치가 없는 기술이 나쁜 것처럼 제대로 구현되지 않은 보호 장치는 상황을 악화시킬 수 있다는 점을 명심해야 합니다.