만화로 보는 DNS over HTTPS

사용자의 프라이버시와 보안에 대한 위협이 커지고 있습니다. Mozilla 는 이런 위협들을 면밀히 관찰하고 있습니다. Mozilla 는 Firefox 사용자와 그들의 데이터를 보호하기 위해 할 수 있는 모든 일을 해야 한다는 책임감을 느낍니다.

Mozilla 는 은밀하게 사용자의 데이터를 수집하려 하고 판매하려 하는 회사들과 조직들을 알고 있습니다. 바로 추적 금지 기능Facebook Container 확장기능을 만든 이유입니다. 이제 곧 당신은 Mozilla 가 사용자 보호를 위해 더 많은 일을 하고 있음을 알게 될 것입니다.

Icons for security projects that we’ve introduced

Mozilla 는 지금까지의 노력에 다음 두 가지를 더 추가하려고 합니다.

  • DoH (DNS over HTTPS).
    IETF 가 새로 표준화 하려는 기능으로 Mozilla 가 제안 대회에서 우승했습니다.
  • TRR (Trusted Recursive Resolver).
    보안을 고려한 DNS 리졸버입니다. Cloudflare 와 협력하여 제공하는 새로운 기능입니다.

이 두 가지 성과를 가지고 우리는 35년 전에 만들어진 도메인 네임 시스템의 데이터 노출 문제를 종식시키려고 합니다. 이에 관한 테스트에 많은 도움 부탁 드립니다. 이제 DoH (DNS over HTTPS) 기능과 TRR (Trusted Recursive Resolver) 기능이 어떻게 사용자를 보호하는지 살펴봅시다.

하지만 그보다 먼저, 웹 페이지가 인터넷 상에서 어떻게 전달되는지부터 살펴봅시다.

DNS 와 HTTPS 의 동작 방식을 이미 이해하고 있다면 DNS over HTTPS 의 문제 해결 방식으로 건너 뛰어도 좋습니다.

HTTP 핵심 특강

브라우저가 웹 페이지를 다운로드하는 과정을 보통 다음과 같이 설명합니다.

  1. 당신의 브라우저가 서버에 GET 요청을 전달합니다.
  2. 서버가 HTML 파일이 담긴 응답을 전달합니다.

browser GET request + response

이게 HTTP 의 통신 방식입니다.

하지만 지나치게 단순화된 설명입니다. 당신의 브라우저는 처음부터 서버와 막바로 대화하지 않습니다. 왜냐하면 브라우저와 서버는 바로 옆에 붙어 있지 않기 때문입니다.

아마도 서버는 수천 마일 밖에 있을 것입니다. 그리고 당신의 컴퓨터와 서버는 어떤 회선으로 직접 연결되어 있지도 않을 것입니다.

image of client and server on opposite ends of the network

그래서 브라우저에서 서버로 요청이 전달되려면, 중간에 여러 손을 거쳐야 합니다. 서버로부터 응답이 되돌아 올 때도 마찬가지입니다.

수업시간에 꼬마들이 쪽지를 주고 받는 것과 같은 방식입니다. 쪽지 겉면에는 누구에게 전달되어야 하는지 적혀있습니다. 쪽지를 만든 꼬마는 자기 이웃에 있는 아이에게 쪽지를 전달합니다. 그러면 그 아이는 또 자기 이웃에 있는 다른 아이에게 쪽지를 전달합니다. 아마 그 아이도 최종 수신자는 아닐 것입니다. 최종 수신자 방향에 있는 누군가겠지요.

kids passing notes

이 방식의 문제점은 중간 경로에 있는 누구라도 쪽지를 읽을 수 있다는 것입니다. 그리고 사전에 쪽지가 어떤 경로로 전달될지 알 수 없습니다. 그래서 어떤 아이들이 쪽지를 보는지 알 수 없습니다.

어떨 때는 쪽지가 나쁜 짓을 하는 아이의 손에 떨어질 수도 있습니다…

쪽지의 내용을 모두에게 공개하는 짓 말이죠.

kid saying “Ooo, hey everybody… Danny loves Sandy!”

또는 응답 내용을 바꾸는 짓도 있습니다.

kid saying “Do you like me? Y/N… Heh, I’m going to prank him and put no here”

이런 문제를 해결하기 위해, 새로운, 보안상 안전한 HTTP 가 만들어졌습니다. HTTPS 말입니다. HTTPS 는 모든 메시지에 자물쇠를 거는 것입니다.

open envelope next to locked envelope

자물쇠를 여는 번호는 브라우저와 서버 말고는 중간 단계의 누구도 알지 못합니다.

이렇게 함으로써, 메시지가 여러 라우터들을 거쳐도, 오직 당신과 웹사이트만 내용을 읽을 수 있습니다.

이 방식은 아주 많은 보안 문제를 해결합니다. 하지만 이 방식을 사용할 때도 당신의 브라우저와 서버 사이에는 여전히 암호화되지 않고 전달되는 메시지들이 있습니다. 즉 중간 단계에 있는 사람들이 여전히 당신의 행동을 감시할 수 있습니다.

여전히 데이터가 노출되는 지점은 바로 서버와 커넥션을 맺는 단계에서 입니다. 당신이 서버에 처음으로 메시지를 전달할 때, 당신은 “Server Name Indication” 필드에 서버 네임을 함께 전달합니다. 이 필드 데이터를 이용해서 하나의 머신에서 여러개의 사이트를 운영하는 서버 운영자가 당신이 통신하고 싶어하는 상대를 파악할 수 있습니다. 이 초기 요청은 암호를 설정하는 단계의 일부로 사용됩니다. 하지만 초기 요청 자체는 암호화되지 않죠.

데이터가 노출될 수 있는 또다른 지점은 DNS 입니다. 그런데 DNS 가 뭐죠?

DNS: Domain Name System

앞서 얘기한 쪽지 전달 비유에서, 저는 수신자의 이름이 쪽지 겉면에 적혀있다고 설명했습니다. 이것은 HTTP 요청에서도 사실입니다… 모든 요청은 어디에 전달되어야 하는지 밝혀야 합니다.

하지만 당신은 상대의 이름을 이용할 수 없습니다. 어떤 라우터도 당신이 말하는 이름을 이해하지 못합니다. 대신, 당신은 IP 주소를 이용해야 합니다. 그것이 중간 경로에 있는 라우터가 당신이 요청을 보내고자 하는 서버를 식별하는 방식입니다.

network with IP addresses

여기에는 문제가 있습니다. 당신은 사용자가 당신 웹사이트의 IP 주소를 기억하리라고 기대하지 못할 것입니다. 대신 당신은 당신의 웹사이트에 기억하기 쉬운 이름을 부여하고 싶을 것입니다… 사용자가 기억할만한 이름 말입니다.

이런 이유로 우리는 도메인 네임 시스템(DNS : Domain Name System)을 필요로 합니다. 당신의 브라우저는 DNS 를 이용해서 사이트 이름을 IP 주소로 변환합니다. 도메인 네임을 IP 주소로 바꾸는 이런 과정을 도메인 네임 레졸루션(Domain Name Resolution)이라고 합니다.

domain and address equivalence

브라우저는 이런 변환 방법을 어떻게 알고 있을까요?

가능한 방법 하나는 전화번호부처럼 하나의 거대한 목록을 유지하는 것입니다. 하지만 이 방식은 새로운 웹사이트가 생기거나 어떤 웹사이트의 주소가 바뀌는 경우, 목록을 최신 상태로 유지하기가 무척 번거롭습니다.

그래서 모든 도메인 네임을 모두 관리하는 하나의 거대한 목록을 유지하는 대신, 서로 연결된 수많은 작은 목록들을 사용합니다. 이렇게 하면 작은 목록들을 서로 독립적으로 관리할 수 있습니다.

one list, vs lots of smaller lists

어떤 도메인 네임의 IP 주소를 찾으려면, 당신은 그 도메인 네임이 포함된 목록을 찾아야 합니다. 마치 보물찾기 같죠.

위키피디아의 영문 사이트 en.wikipedia.org 에 대한 보물찾기 과정을 알아볼까요?

우선 도메인 네임을 작은 부분들로 나눕니다.

domain split into top level, second level, and subdomain.

이렇게 나눠 진 부분들을 이용해서 우리는 해당 사이트의 IP 주소를 담고 있는 목록을 찾을 수 있습니다. 이 과정에서 도움을 주는 어떤 장치가 필요합니다. 리졸버(resolver)라고 불리는 장치입니다. 리졸버는 우리 대신 보물찾기를 수행해서 IP 주소를 찾아 줍니다.

먼저, 리졸버는 Root DNS 라 불리는 서버와 이야기합니다. 리졸버는 몇 개의 Root DNS 서버들을 알고 있으며 그 중 하나에 요청을 전달합니다. 리졸버는 Root DNS 서버에게 톱레벨(top-level) 도메인 .org 주소들을 어디서 찾을 수 있는지 질문합니다.

Root DNS 서버는 리졸버에게 .org 주소들을 알고 있는 서버의 주소를 전달합니다.

resolver talking to Root DNS

다음 서버는 톱레벨 도메인 (TLD : Top-Level Domain) 네임 서버입니다. TLD 네임 서버는 .org 으로 끝나는 모든 2번째 도메인들에 대한 정보를 알고 있습니다.

하지만 wikipedia.org 아래의 서브 도메인 주소는 모릅니다. 즉 TLD 네임 서버는 en.wikipedia.org 의 IP 주소를 모릅니다.

TLD 네임 서버는 리졸버에게 Wikipedia 의 네임 서버에게 물어보라고 일러줄 것입니다.

resolver talking to TLD DNS

리졸버의 일이 거의 끝나갑니다. Wikipedia 의 네임 서버를 오쏘러테이티브 서버 (Authoritative Server)라고 부릅니다. 오쏘러테이티브 서버는 wikipedia.org 아래의 모든 주소를 알고 있습니다. 즉 이 서버는 en.wikipedia.org 주소를 알고 있으며, de.wikipedia.org 같은 독일어 버전 위키피디아의 주소도 알고 있습니다. 오쏘러테이티브 서버는 리졸버에게 어떤 IP 주소가 웹사이트의 HTML 파일을 갖고 있는지 말해줍니다.

resolver talking to authoritative DNS

리졸버는 en.wikipedia.org 의 IP 주소를 운영체계(OS)에 전달합니다.

이 과정을 리커시브 레졸루션(Recursive Resolution)이라고 부릅니다. 왜냐하면 여러 서버들을 오가며 기본적으로 같은 질문을 반복해서 하기 때문입니다.

제가 우리에게 모험을 도와줄 리졸버가 필요하다고 말했습니다. 그런데 브라우저는 어떻게 이 리졸버를 알아낼까요? 보통, 브라우저는 컴퓨터의 운영체계(OS)에게 리졸버를 달라고 요청합니다.

browser asking OS for resolver

운영체계(OS)는 어떤 리졸버를 써야 하는지 어떻게 알까요? 두 가지 방법이 있습니다.

하나는 당신이 직접 신뢰할 수 있는 리졸버를 설정하는 것입니다. 하지만 이렇게 하는 사람은 아주 드뭅니다.

대신, 대부분의 사람들은 그냥 디폴트 설정을 사용합니다. 디폴트 상태에서 OS 는 네트워크가 일러주는 리졸버를 그대로 사용합니다. 컴퓨터를 네트워크에 연결하면 네트워크는 컴퓨터에 IP 주소를 할당하고 사용할 리졸버를 추천해줍니다.

operating system getting a recommendation from the network

이것은 당신이 사용하는 리졸버가 하루에도 여러번 바뀔 수 있다는 것을 의미합니다. 만약 당신이 오후에 커피숍에 가서 업무를 본다면, 아마도 당신은 오전에 사용한 것과 다른 리졸버를 사용할 것입니다. 그리고 이것은 당신이 리졸버를 직접 설정하는 경우에도 마찬가지입니다. DNS 프로토콜에는 보안(security)이 전혀 고려되어 있지 않기 때문입니다.

DNS 는 어떻게 악용될 수 있나요?

그래서 이 시스템이 어떻게 사용자를 위협할 수 있나요??

통상 리졸버는 각 DNS 서버에게 당신이 찾는 도메인을 묻습니다. 이런 요청에 당신의 전체 IP 주소가 포함됩니다. 전체 IP 주소가 아니더라도 당신 IP 주소의 대부분이 포함됩니다. 이를 다른 정보와 조합하면 당신이 누구인지 알아낼 수 있습니다.

DNS request

다시 말해 당신이 도메인 네임을 해석하기 위해 질문을 던지는 모든 서버들이 당신이 무슨 사이트를 찾는지 지켜볼 수 있습니다. 더 심한 것은, 당신과 DNS 서버들 사이의 경로에 있는 누군가도 당신의 요청을 볼 수 있다는 것입니다.

DNS 시스템이 사용자의 데이터를 위험에 빠뜨리는 몇 가지 경우가 있습니다. 그 중 중요한 두 가지 위협은 트래킹(Tracking : 추적)과 스푸핑(Spoofing : 위장)입니다.

트래킹 (Tracking : 추적)

위에서 언급한 것처럼, 전체 IP 주소 또는 일부 IP 주소를 가지고 어떤 웹사이트를 찾는 사람이 누구인지 밝혀내는 것은 쉬운 일입니다. 이는 DNS 서버와 거기에 이르는 경로에 있는 누군가(경로 라우터라고 불립니다)가 당신에 관한 프로필을 만들 수 있다는 것을 의미합니다. 그들은 그들이 지켜본 내용을 기초로 당신이 찾았던 모든 웹사이트들의 기록을 만들 수 있습니다.

그 데이터는 무척 귀한 데이터입니다. 당신 찾는 웹사이트 내역을 알 수 있다면, 많은 사람들과 회사들이 기꺼이 큰 돈을 치르려 할 것입니다.

a router offering to sell data

악의적인 DNS 서버나 경로 라우터의 존재를 걱정할 필요가 없다 해도 여전히 당신에 관한 데이터가 수집되고 판매될 가능성이 있습니다. 리졸버 그 자체가 문제입니다. 네트워크가 당신에게 건네준 리졸버가 신뢰할 수 없는 것일 수 있습니다.

네트워크가 추천해준 리졸버를 믿는다고 해도 그 리졸버는 집에서만 사용하는 것입니다. 위에서 말한 것처럼 당신이 커피숍이나 호텔 등에 가서 다른 네트워크를 사용할 경우, 당신은 아마도 다른 리졸버를 사용할 겁니다. 그 리졸버의 데이터 수집 정책이 어떤지 누가 알겠습니까?

당신이 모르는 새에 동의도 없이 당신의 데이터를 수집하고 판매하는 것 말고도 시스템이 당신을 속이는 더 나쁜 방법이 있습니다.

스푸핑 (Spoofing : 위장)

스푸핑이란, 당신과 DNS 서버 사이에 있는 누군가가 DNS 서버의 응답을 변경하는 것입니다. 당신에게 진짜 IP 주소를 알려주는 대신, 스푸핑 하는 사람은 웹사이트에 대한 가짜 IP 주소를 전달합니다. 이렇게 함으로써 그들은 당신이 진짜 웹사이트에 방문하는 것을 막거나 스캠(scam) 웹사이트를 보여줍니다.

spoofer sending user to wrong site

또 하나 리졸버 자체가 악의적으로 동작하는 경우가 있습니다.

당신이 Megastore 에서 무언가 사고 싶어한다고 가정해봅시다. 그리고 경쟁 온라인 쇼핑몰인 big-box.com 에서 더 싼 가격에 살 수 있는지 가격비교를 하고자 한다고 가정해봅시다.

만약 당신이 Megastore 의 WiFi 를 쓰고 있는 중이라면, 아마도 당신은 그들이 제공하는 리졸버를 사용할 것입니다. 그리고 그 리졸버는 big-box.com 로 가는 요청을 가로채서 해당 웹사이트에 접속할 수 없다고 거짓말할 수도 있을 것입니다.

TRR 과 DoH 로 어떻게 문제를 해결할 수 있나요?

Mozilla 는 우리의 사용자들과 그들의 데이터를 지키는 것에 대해 큰 책임감을 느낍니다. 우리는 이런 취약점을 해결하기 위해 노력해왔습니다.

이 문제를 해결하기 위한 두 가지 방안을 소개합니다. TRR (Trusted Recursive Resolver) 과 DoH (DNS over HTTPS) 입니다. 실제로는, 여기에 세 가지 위협이 있습니다.

  1. 신뢰할 수 없는 리졸버를 사용하는 경우입니다. 이런 리졸버는 당신의 요청을 추적하거나 DNS 서버의 응답을 변조합니다.
  2. 같은 방식으로 경로 라우터들이 추적이나 변조 행위를 할 수 있습니다.
  3. DNS 서버들이 당신의 DNS 요청을 추적할 수 있습니다.

the three threats—resolvers, on-path routers, and DNS servers

그래서 우리는 이 문제들을 어떻게 해결하나요?

  1. TRR (Trusted Recursive Resolver) 를 사용함으로써 신뢰할 수 없는 리졸버 사용을 피합니다.
  2. DoH (DNS over HTTPS) 를 사용함으로써 경로 상에서의 도청을 방지합니다.
  3. 가능한 최소한의 데이터만 전송해서 사용자를 식별하지 못하게 합니다.

TRR 을 사용함으로써 신뢰할 수 없는 리졸버 사용을 회피

아주 적은 사람만이 그 위험성과 스스로 지키는 방법을 알고 있기 때문에 당신의 데이터를 훔치는 리졸버나 당신에게 거짓 응답을 제공하는 Spoof DNS 가 네트워크 상에 존재하는 것이 가능합니다.

그 위험성을 아는 사용자들도, 개인 입장에서는 인터넷 제공 업자(ISP)나 다른 기관들과 협상해서 자신의 DNS 데이터가 책임 있게 처리되도록 보호하기 힘듭니다.

하지만, 우리는 오랜 기간 이런 위험성에 대해 연구해왔습니다… 그리고 우리는 협상력을 가지고 있습니다. 우리는 사용자의 DNS 데이터를 보호하기 위해 우리와 함께 일할 회사를 찾기 위해 노력했습니다. 그래서 찾았습니다. Cloudflare 입니다.

Cloudflare 는 사용자 친화적인 프라이버시 정책과 함께 RRS (Recursive Resolution Service) 를 제공합니다. Cloudflare 는 24시간마다 사용자를 식별에 사용될 수 있는 모든 데이터를 폐기하며, 그 데이터를 제 3자에게 제공하지 않습니다. 그리고 그 데이터가 규정대로 폐기되었음을 증명하는 감사 자료를 제공합니다.

이제, 우리는 사용자의 프라이버시를 보호하는 신뢰할 수 있는 리졸버를 갖게 된 것입니다. 이는 이제 Firefox 가 네트워크가 제공하는 리졸버를 무시하고 Cloudflare 의 리졸버를 사용할 수 있게 됐음을 의미합니다. 신뢰할 수 있는 리졸버를 확보함으로써 우리는 사용자 데이터를 팔아먹는 리졸버나 가짜 응답을 제공하는 Spoof DNS 에 대한 걱정을 할 필요가 없어졌습니다.

왜 리졸버를 하나만 선택할까요? Cloudflare 는 우리가 프라이버시를 우선시하는 DNS 서비스를 만들자고 제안한 것에 대해 열광했습니다. Cloudflare 는 우리와 함께 DoH 레졸루션 서비스를 만들었습니다. DoH 레졸루션 서비스는 Firefox 사용자에게 아주 투명한 방식으로 서비스를 제공합니다. Cloudflare 는 사용자 보호 기능을 추가하는 것에 대해 개방적이었습니다. 그래서 우리는 그들과 협업하는 것이 행복합니다.

하지만 그렇다고 당신이 반드시 Cloudflare 를 사용해야 하는 것은 아닙니다. 사용자들은 원한다면 Firefox 가 DoH 를 지원하는 다른 TRR(Trusted Recursive Resolver)을 사용하도록 설정할 수 있습니다. TRR 을 지원하는 생태계가 커지면, 우리는 TRR 을 쉽게 발견하고 전환하는 기능을 추가할 것입니다.

DoH (DNS over HTTPS) 를 사용함으로써 경로 상에서의 도청을 방지

그런데, 리졸버가 위협의 전부는 아닙니다. 경로 라우터들도 DNS 기록을 수집하고 위장할 수 있습니다. 경로 라우터들도 DNS 요청과 응답을 들여다 볼 수 있습니다. 하지만 인터넷에는 이런 도청을 막는 기술이 이미 존재합니다. 바로 암호화 기술입니다.

DNS 패킷 전달 과정에 HTTPS 를 사용하면, 누구도 사용자가 만드는 DNS 요청을 도청할 수 없습니다.

최소한의 데이터만 전송해서 사용자 식별을 방지

신뢰할 수 있는 리졸버를 제공하고 DoH 프로토콜을 이용해서 통신하는 것에 더해서, Cloudflare 와 Mozilla 는 상황을 좀 더 안전하게 만들려고 합니다.

통상, 리졸버는 도메인 네임 전부를 모든 서버들(루트 DNS, TLD 네임서버, 2차 네임서버 등)에 전달합니다. 하지만 Cloudflare 는 약간 다른 방식으로 동작할 것입니다. Cloudflare 는 상대하는 DNS 서버에 따라 꼭 필요한 일부 정보만 전달할 것입니다. 이것을 QNAME minimization 이라고 부릅니다.

image showing resolver only asking the relevant question

또 리졸버는 통상 요청을 보낼 때 당신 IP 주소의 처음 24비트를 포함시켜 보냅니다. DNS 서버는 이 정보를 이용해서 당신 근처의 CDN 을 골라 추천해줍니다. 하지만 이 정보는 DNS 서버들이 다른 불순한 용도로 악용하기 쉽습니다.

대신, Cloudflare 는 Cloudflare 이 보유한 당신 근처의 다른 IP 주소를 이용해서 DNS 요청을 만듭니다. 이렇게 하면 지리적 정보를 제공하면서도 사용자를 식별하지 못하게 할 수 있습니다. 우리는 프라이버시를 보호하면서도 정밀하게 로드 밸런싱을 할 수 있는 더 나은 방법을 계속 찾고 있습니다.

이렇게 도메인 네임에서 불필요한 부분을 없애고 당신의 IP 주소를 포함시키지 않으면 DNS 서버가 당신에 관한 정보를 수집하기 어려워집니다.

DNS request with client subnet and first part of domain cross out

TRR 과 DoH 을 써도 고쳐지지 않는 것이 있나요?

이런 방법을 사용함으로써, 당신이 어떤 사이트를 방문하는지 들여다 볼 수 있는 사람의 수를 줄였습니다. 하지만 이렇게 해도 데이터 유출 위험이 완전히 없어지는 것은 아닙니다.

IP 주소를 찾기 위해 DNS 검색을 한 다음, 당신은 해당 주소의 웹서버와 커넥션을 맺어야 합니다. 그러기 위해, 당신은 초기 요청(initial request)을 보내야 합니다. 이 요청에는 SNI(Server Name Indication) 정보가 포함되어 있습니다. SNI 는 당신이 해당 서버가 제공하는 여러 사이트들 중 어떤 사이트에 접속하고 싶어 하는지 표시합니다. 그리고 이 요청은 암호화되어 있지 않습니다.

이것은 당신이 사용하는 인터넷 서비스 제공자가 여전히 당신이 어떤 사이트를 방문하는지 알아낼 수 있다는 것을 의미합니다. SNI 가 바로 그 정보를 담고 있으니까요. 그리고, 당신 브라우저에서 웹서버로 전송되는 그 초기 요청을 전달하는 라우터들도 그 정보를 볼 수 있습니다.

하지만, 일단 그 웹서버와 커넥션이 이루어지고 나면, 그 다음부터는 모든 것이 암호화됩니다. 그리고 멋진 일은 이 암호화된 커넥션을 해당 서버가 제공하는 다른 사이트를 보기 위해 계속 사용할 수 있다는 것입니다. 처음에 요청했던 사이트 말고요.

이것이 HTTP/2 커넥션 합치기 (Connection Coalescing), 또는 간단히 커넥션 재사용 (Connection Reuse)이라고 불리는 기술입니다. 당신이 이 기술을 제공하는 어떤 서버와 커넥션을 맺을 경우, 그 서버는 자신이 제공하는 다른 사이트들의 존재를 알려줄 것입니다. 그러면 당신은 이미 맺은 암호화된 커넥션을 이용해서 그 사이트들을 방문할 수 있을 것입니다.

이것이 왜 좋을까요? 당신이 다른 사이트들을 방문하기 위해 새로운 커넥션을 새로 맺을 필요가 없기 때문입니다. 이는 당신이 암호화되지 않은 초기 요청을 다시 보낼 필요가 없다는 것을 의미합니다. 당신이 방문하고 싶어하는 SNI 정보가 담긴 요청 말입니다. 그러면 당신은 인터넷 서비스 제공자와 경로 라우터들에게 어떤 정보도 노출하지 않고 원하는 사이트들을 방문할 수 있습니다.

CDN 이 보편화되면서, 점점 더 많은 독립적인 사이트들이 동일한 서버에 의해 제공되고 있습니다. 그리고 당신은 합쳐진 커넥션 (Coalesced Connections)을 여러 개 동시에 열 수 있습니다. 다시 말해 당신은 여러 개의 공유 서버들 또는 CDN 서버들과 동시에 여러 개의 커넥션을 맺을 수 있고, 그 서버들이 제공하는 모든 사이트들을 데이터 노출 없이 방문할 수 있습니다. 이것은 프라이버시 보호 관점에서 매우 효과적인 수단이 될 것입니다.

현재 상태는요?

당신은 오늘 당장 Firefox 의 DoH (DNS over HTTPS) 기능을 켤 수 있습니다. 우리는 당신이 그러기를 바랍니다.

우리는 이 기능을 모든 사용자들에게 디폴트로 제공할 계획입니다. 우리는 모든 사용자들이 이런 프라이버시 보호 기능을 누려야 한다고 생각합니다. 그들이 DNS 정보 노출에 대해 이해하고 있지 않더라도 말이죠.

하지만 이것은 커다란 변화입니다. 그래서 우리는 더 많은 테스트를 해야 할 필요가 있습니다. 우리가 연구를 계속하는 이유입니다. 우리는 우리의 Firefox Nightly 사용자들에게 성능 데이터 수집에 관한 도움을 요청했습니다.

우리는 지금처럼 디폴트 리졸버를 사용할 것입니다. 하지만 동시에 동일한 요청을 Cloudflare 의 DoH 리졸버에게도 전달할 것입니다. 그래서 우리는 그 둘을 비교해서 모든 것이 우리가 예측한대로 동작하는지 검증할 것입니다.

이 연구 참가자들을 위해, Cloudflare DNS 의 응답은 사용되지 않고 단지 제대로 동작하는지 체크하는 용도로만 사용될 것입니다. 그리고 Cloudflare 의 응답은 폐기될 것입니다.

diagram showing a person timing both and then throwing away Cloudflare response

매일매일 Firefox 를 테스트해주는 Nightly 사용자들의 응원에 감사 드립니다. 이번 테스트도 잘 도와주시면 좋겠습니다.


이 글은 Lin Clark 이 쓴 A cartoon intro to DNS over HTTPS 의 한국어 번역본입니다.
이 글은 2018년 5월 발행된 글이며 이 글에 언급된 “DNS over HTTPS” 기능은 이미 Firefox 에 기본 탑재되어 있습니다.

작성자: ingeeKim

"누구에게나 평등하고 자유로운 웹"에 공감하는 직장인.

ingeeKim가 작성한 문서들…


댓글이 없습니다.

댓글 쓰기