몇 년에 한 번씩 누군가 이메일을 고치겠다고 선언한다. 종단간 암호화하고, 스팸을 없애고, 스푸핑을 불가능하게 만들고, 삐걱대는 이 구조물 전체를 현대적인 무언가로 교체하겠다고. 그들은 결코 해내지 못한다. 똑똑하지 않아서가 아니라, 문제를 잘못 읽었기 때문이다. 이메일은 좋은 엔지니어를 기다리는 고장 난 물건이 아니다. 그건 잘 작동하는 물건인데, 그 토대가 — 이메일이기를 그만두지 않는 한 — 결코 안전해질 수 없음을 보장한다.
내가 무슨 말을 하는지 정확히 하자. “이메일은 망가졌다”는 게으른 말이고, 나는 더 날카로운 걸 말하고 싶으니까.
원죄
SMTP는 1982년 RFC 821에서 정의됐다. 오늘 읽으면 인상적인 건 빠진 게 무엇이냐가 아니라, 그 누락이 얼마나 합리적이었느냐다. 인증이 없다. 전혀. 서버가 접속해 MAIL FROM:<anyone@anywhere>라고 말하고, 수신자 몇을 지정하고, 메시지를 보내면, 받는 서버가 그걸 수락한다. 발신자가 주장하는 그 사람이 맞는지 아무도 확인하지 않는다. 1982년에 SMTP를 말할 수 있는 기계의 집합은 작고, 알려져 있었고, 대체로 서로 아는 사람들이 운영했기 때문이다. 그 네트워크에 암호학적 신원을 더하는 건 텐트에 데드볼트를 다는 격이었을 것이다.
설계자들은 발신자 주소를 심지어 선택 사항으로 표시했다. RFC에서 밝힌 그 목적은 배달 실패를 보고할 되돌아가는 경로를 시스템에 주는 것 — 봉투에 적힌 반송 주소, 그 이상이 아니었다. 신뢰할 수 있는 신원 주장으로 의도된 적이 없다. 그 하나의 결정이 뒤따른 모든 이메일 보안 문제의 뿌리이며, 왜 그런지 잠시 머물러 볼 가치가 있다.
대부분이 결코 배우지 않는 부분이 여기 있다. 이메일에는 발신자가 둘 있고, 둘이 일치할 필요가 없다. 봉투 발신자 — 서버들이 SMTP 대화 중 주고받는 MAIL FROM으로, RFC 5321이 정의한다. 그리고 From: 헤더 — 당신이 메일 클라이언트에서 실제로 보는 그것으로, 완전히 다른 문서인 RFC 5322가 정의한다. 봉투는 메일을 라우팅하고, 헤더는 사람에게 표시된다. 프로토콜의 그 무엇도 이 둘이 같은 주소이길 요구하지 않는다. 메시지가 bounces@marketing-vendor.com에서 봉투가 붙고 From: ceo@yourbank.com으로 표시될 수 있으며, 그건 버그도 익스플로잇도 아니다 — 메일링 리스트와 포워딩, 그리고 남을 대신해 발송하는 모든 정당한 서비스가 설계 그대로 작동하는 것이다.
그러니 스푸핑은 누가 닫는 걸 잊은 구멍이 아니다. 명세된 동작이다. 프로토콜은 누구든 누구라고 주장할 수 있게 만들어졌다. 그 세계에서 그건 기능이었으니까.
패치의 탑
이제 신뢰 없이 설계된 — 그리고 결정적으로 끌 수 없는, 수천만 대의 서버가 1982년 버전을 말하고 앞으로도 그럴 — 프로토콜에 신뢰를 사후 이식하려 할 때 무슨 일이 벌어지는지 보자.
SPF (RFC 7208, 2014)가 첫 패치였다. 어떤 IP 주소가 당신 도메인의 메일을 보낼 수 있는지 나열한 DNS 레코드를 게시한다. 수신자는 접속한 IP를 목록과 대조한다. 합리적이다 — 다만 SPF는 아무도 보지 않는 봉투 발신자를 검증하지, 사용자가 읽는 From: 헤더가 아니다. 그래서 SPF는 위조된 From:을 표시하는 메시지에도 통과할 수 있다. 그리고 SPF는 메시지가 포워딩되는 순간 깨진다. 포워딩은 원래 봉투 발신자는 보존하면서 발송 IP를 바꾸기 때문이다. 20년이 지나도 메일링 리스트는 완벽하게 정당한 메일에 대해 여전히 SPF를 일상적으로 실패시킨다.
DKIM (RFC 6376, 2011)이 두 번째 패치였다. 선택한 헤더와 본문을 개인 키로 서명하고, 공개 키를 DNS에 게시하고, 서명이 전송을 견뎌냈는지 수신자가 검증하게 한다. 낫다 — 실제로 보이는 From: 헤더를 덮고, 일부 포워딩도 견딘다. 하지만 푸터를 덧붙이거나 제목을 다시 쓰는 메일링 리스트는 서명을 깨뜨리고, 유효한 DKIM 서명은 어떤 도메인이 메시지에 서명했다는 것만 증명하지, 서명한 도메인이 From: 줄의 도메인과 일치한다는 걸 증명하지 않는다.
그래서 앞의 둘을 뭔가 의미 있게 만들려면 세 번째 패치가 필요했다. DMARC (RFC 7489, 2015)는 SPF와 DKIM을 사용자가 실제로 보는 From: 헤더에 묶기 위해 — *정렬(alignment)*이라 부르는 속성 — 그리고 둘 다 정렬되지 않을 때 수신자가 무엇을 할지 알려주기 위해 존재한다. 잠시 머물러 보라. 이메일 스푸핑에 맞선 인터넷의 주요 방어책은, 앞선 두 스푸핑 방지 장치를 그 둘이 검사하길 잊은 필드에 볼트로 조이는 게 유일한 일인 메커니즘이다. 그리고 모든 걸 말해주는 디테일이 여기 있다. DMARC는 IETF 표준 트랙 문서조차 아니다. RFC 7489는 Informational이고, 독립 제출 스트림으로 발행됐다. 인터넷에서 가장 중요한 이메일 인증 표준이 실제 표준으로 비준된 적이 없다.
DMARC도 물론 포워딩을 깨뜨린다 — IP가 바뀌어 SPF가 실패하고 리스트가 본문을 뭉개서 DKIM이 실패하면, 정렬된 메시지가 거부된다. 그래서 네 번째 패치, ARC (RFC 8617)가 필요했다. 중간 장비가 메시지를 건드리기 전에 인증이 통과했음을 보증하게 해서, 최종 수신자가 그 체인을 믿기로 선택할 수 있게. 원래 프로토콜을 인증한 패치를 고치는, 그 패치를 보존하기 위한, 패치.
암호화는 아직 꺼내지도 않았다. SMTP는 평문이라 STARTTLS (RFC 3207)가 두 서버로 하여금 기회주의적으로 연결을 TLS로 업그레이드하게 한다. 기회주의적으로 — 즉 업그레이드가 실패하거나, 중간자가 인사말에서 STARTTLS 기능을 그냥 벗겨내면, 서버들은 실패하는 대신 당신의 메일을 평문으로 보내는 걸로 후퇴한다. 네트워크에서 조용히 끌 수 있는 암호화다. 그것을 막으려고 우리는 MTA-STS (RFC 8461)를 얻었다 — HTTPS로 게시되어 발신자에게 “진짜로, 나한테 닿으려면 TLS를 요구해”라고 말하는 정책. 암호화 패치가 열어둔 다운그레이드를 존중하지 말라고 서버에 지시하는 패치.
세어 보라. SPF, DKIM, DMARC, ARC, STARTTLS, MTA-STS — 30년에 걸친 여섯 프로토콜, 그리고 하나하나가 바로 앞의 것이 남긴 틈을 덮으려 존재하며, 전부 선택 사항이고, 전부 보안이 전혀 없다고 가정하는 1982년 프로토콜과 하위 호환된다.
”그냥 교체하자”가 환상인 이유
이런 반론이 있다. 좋다, 그럼 깨끗한 후계자를 설계해라. 신원과 암호화가 9계층에 스테이플로 박히는 대신 1계층에 구워 넣어진 현대적 메시징 프로토콜을.
사람들은 그렇게 했다. Signal, iMessage, WhatsApp, Slack, 그리고 보안 이메일 스타트업의 무덤이라 불린다. 그리고 성공한 것들이 무엇을 했는지 보라. 그들은 이메일을 교체하지 않았다. 그 옆에 담장 두른 정원을 짓고 친구들을 데려오라고 말했다. 그게 채팅에선 통한다. 채팅은 사회적이니까 — 당신과 대화 상대가 모두 한꺼번에 옮길 수 있다. 이메일의 가치는 정확히 그것이 담장 두른 정원이 아니라는 데 있다. 어떤 제공자의 어떤 주소를 가진 누구든, 공유 앱도 같은 플랫폼의 계정도 없이 다른 누구에게든 닿을 수 있다. 그 보편성이 제품 전체다. 그리고 그것은 이메일을 안전하지 않게 만드는 바로 그것과 분리 불가능하다. 이메일은 SMTP를 말해본 모든 서버와, 누구에게서 왔다고 주장하는 비인증 평문 메시지를 기꺼이 수락하는 1982년의 그 서버까지 포함해, 상호운용해야 한다.
정의하는 특징이 모두로부터 메일을 받는 것인 네트워크에 필수 보안 요건을 더할 수는 없다. 그걸 필수로 만드는 순간 모두로부터 메일을 받는 걸 멈추고, @ 기호를 쓰는 담장 두른 정원을 지은 게 되기 때문이다. 프로토콜의 가장 큰 강점과 고칠 수 없는 약점은 같은 속성이다. 하나만 취하고 다른 하나를 버릴 수는 없다.
”고칠 수 없다”가 실제로 뜻하는 것
포기하라는 게 아니다. SPF, DKIM, DMARC는 배포할 가치가 있고 — 나는 모두가 해야 한다고 주장하겠다 — 셋 다 제대로 정렬된 도메인은 진짜로 스푸핑하기 어렵다. 패치는 그 한계 안에서 작동한다. 배포하라.
하지만 자신이 무엇을 하는지에 대해 정직하라. 당신은 이메일을 고치는 게 아니다. 1982년에 작은 네트워크의 모두를 믿기로 한 결정 — 그때는 옳았고 지금은 되돌릴 수 없는, 그 결정이 만든 네트워크가 너무 크고 너무 오래되고 너무 유용해서 교체할 수 없기에 되돌릴 수 없는 — 의 영구적 결과를 관리하는 것이다. 모든 “이메일 보안” 제품은 그 결정 위의 패치다. 이것이 깨끗하고 안전한 이메일 프로토콜로 끝나는 버전은 없다. 깨끗하고 안전한 그 프로토콜은 인터넷으로부터 메일을 받지 못할 것이고, 인터넷으로부터 메일을 받는 것이 곧 이메일이기 때문이다.
이메일은 프로토콜의 바퀴벌레다. 그것을 대체하려 만든 모든 시스템보다 오래 살아남을 것이다. 불완전하고 죽지 않는 채로, 정확히 참여하는 데 누구도 신뢰할 만할 것을 요구하지 않았기에. 그게 실수였다. 그리고 그게 지금도 작동하는 이유다.