Chrome은 DNS를 암호화했다. 검증한 적은 없다.

Chrome에서 보안 DNS를 켜면 리졸버로 가는 파이프가 암호화된다. 돌아온 답이 진짜라는 증명은 전혀 하지 않는다. 암호화와 인증은 다른 문제이고, 브라우저는 조용히 하나만 골랐다.

Chrome 설정에 “보안 DNS 사용”이라는 토글이 있다. 여기서 무거운 짐을 지는 단어가 “보안”인데, 대부분은 이걸 “안전”으로 읽고, 실제 의미는 훨씬 좁다. 켜면 Chrome이 DNS 쿼리를 옛날 평문 UDP — 경로상 누구나 읽을 수 있던 — 대신 HTTPS 위로(DoH) 보낸다. 이건 진짜다. ISP가 더 이상 당신이 조회하는 호스트명을 죄다 로깅하며 앉아 있을 수 없다. 도청자는 사라졌다.

위조자는 안 사라졌다. 그리고 “보안”이라는 단어가 조용히 덮는 게 바로 이 부분이다.

암호화와 인증은 서로 다른 문제인데, 둘 다 “보안”처럼 들려서 끊임없이 뒤섞인다. 암호화는 대화를 감춘다. 인증은 상대가 자기 말대로의 상대이고 메시지가 조작되지 않았음을 증명한다. 보안 DNS는 앞의 것을 한다. 뒤의 것은 안 한다. Chrome이 암호화된 DoH 채널로 yourbank.com을 조회하고 리졸버가 203.0.113.9라고 답하면, Chrome은 그 답이 Chrome과 리졸버 사이 전송 구간에서 아무도 읽거나 바꾸지 않았다는 암호학적 보장을 갖는다. 203.0.113.9가 실제로 당신 은행 주소라는 보장은 하나도 없다. 채널은 봉인됐다. 내용물은 믿음으로 받는다.

이걸 고칠 메커니즘은 존재하는데, 브라우저가 안 돌린다

DNS 답을 인증하는 게 존재 이유 전부인 프로토콜이 있다. DNSSEC다. 레코드에 서명을 붙여서, 검증기가 그 응답이 진짜 존(zone) 소유자에게서 왔고 오는 길에 위조되지 않았음을 증명할 수 있게 한다. “보안 DNS”가 응당 그래야 할 것 같은 그것을 원한다면, DNSSEC 검증이 바로 그것이다.

Chrome은 안 한다. Firefox도 안 한다. 주류 브라우저 중 DNSSEC를 검증하는 건 없고, 이건 아직 손 못 댄 누락이 아니라 — 내리고 고수한 결정이다. Chrome은 사실 비슷한 걸 한번 넣은 적이 있다: DANE용으로 DNSSEC 인증된 레코드를 실어서, 브라우저가 DNS를 통해 인증서를 pin하게 하는 메커니즘. 뜯어냈다. Chrome TLS 스택을 만든 Adam Langley가 2015년에 “Why not DANE in browsers”라는 대놓고 직설적인 제목의 글에서 이유를 풀어놨다. 요약하면: 샌드박스 밖에 사는 파싱 코드 덩어리였고, 쓰는 사람이 거의 없었고, TLS가 가려는 방향과 부딪혔고, DNSSEC가 — 루트 존까지 포함해 — 1024비트 RSA에 기대는데 구글은 그걸 브라우저에서 몰아내려던 참이었다. 그래서 없어졌다.

이유는 솔직히 세월을 잘 견뎠다. 하지만 그 결과, 보통 사람이 “보안 DNS”가 당연히 묶어줄 거라 여기는 두 가지 — 사적인 채널과 믿을 만한 답 — 가 쪼개졌고, 브라우저는 둘 다를 암시하는 이름 아래 정확히 하나만 출시했다.

그래서 켜면 실제로 뭘 얻나

신뢰의 위치를 옮긴다. 그게 어디에 내려앉는지는 냉정하게 볼 필요가 있다.

보안 DNS 이전엔 네트워크가 물려준 리졸버(보통 ISP 것)를 믿었고, 회선 위 누구나 지켜볼 수 있었다. 보안 DNS 이후엔 회선이 어두워지고, 당신이 고른 DoH 제공자 — Cloudflare, Google, Quad9, 누구든 — 를 완전히, 전적으로 믿는다. 그들이 쿼리를 풀어 당신이 독립적으로 검증할 수 없는 답을 건네주니까. 투명하고 엿보이던 ISP와의 관계를, 불투명하고 암호화된 DoH 운영자와의 관계로 맞바꾼 것이다. 카페 와이파이에서 킁킁대는 놈에 대해서는 진짜 프라이버시 업그레이드다. 무결성은 아니다. 리졸버가 틀렸거나, 뚫렸거나, 거짓말하고 있으면 — 혹은 그 리졸버가 조회하는 서명 안 된 존이 상류에서 오염됐으면 — Chrome은 위조된 답을 아름다운 암호화 연결 위로 렌더링하고, TLS가 끝나는 순간 자물쇠까지 보여준다.

그리고 이걸 순수한 탁상공론에서 벗어나게 하는 대목: 압도적 다수의 도메인은 서명돼 있지 않다. 전 세계 DNSSEC 채택률은 몇 년째 도메인의 5분의 1 아래에 붙박여 있다. 그래서 인터넷 대부분에 대해선, 브라우저가 검증하고 싶어도 검증할 서명 자체가 없다. 서명 안 된 도메인에 보안 DNS를 켜면, 스택 어디에서도 암호학적으로 보증한 적 없는 답을 실어 나르는 암호화된 파이프를 얻는다. 기밀성은 진짜다. 진위는 애초에 협상 테이블에 오른 적도 없다.

실제 검증은 어디서 일어나나 (일어난다면)

DNSSEC 검증은, 일어날 때, 브라우저가 아니라 리졸버에서 일어난다. 검증하는 리졸버 — 1.1.1.1, 8.8.8.8, 9.9.9.9, 그리고 진지한 것들 대부분 — 는 서명된 존의 서명을 확인하고 검증에 실패한 답은 반환을 거부한다(거짓말 대신 SERVFAIL이 온다). 좋은 일이고, 오늘날 실제로 인증을 하는 계층이다. 하지만 이게 뭘 뜻하는지 보라: 당신이 얻는 보안은 Chrome 토글에서 나온 게 전혀 아니다. 리졸버가 검증하기로 선택한 데서, 서명된 소수의 존에 한해서, 그리고 리졸버가 그걸 정직하게 했다고 당신이 암호화된 채널 너머로 믿는 데서 나온다. 브라우저는 승객이다. 탑승은 암호화하고, 검증은 아무것도 안 한다.

보안 DNS가 나쁘다고 생각하진 않는다. 나도 켜고 쓴다. DNS 암호화는 진작 됐어야 했고, 수동적 감시 구멍을 막은 건 진짜 성과다. 거슬리는 건 라벨이고, 그게 심어주는 멘탈 모델이다. 한 세대의 사용자가 “보안 DNS”를 켜고, “보안”이라는 단어를 보고, DNS를 “처리됨”으로 분류할 것이다 — 자물쇠 아이콘이 HTTPS를 “암호화됨”이 아니라 “믿을 만함”으로 모두를 설득했던 그 방식 그대로. 자물쇠로 이미 한 번 저지른 실수다. 이제 리졸버로 또 저지르려 한다.

채널을 암호화하는 것과 그 내용을 인증하는 것은 같은 행위가 아니다. Chrome은 하나를 하고 둘 다의 이름을 붙였다. 답이 사적이기만 한 게 아니라 이길 원한다면, 그 일은 여전히 검증하는 리졸버와 서명된 존의 몫이다 — 그리고 인터넷 대부분은 둘 다 없다.

토론 참여

← 블로그로 돌아가기