요약
이메일 종단간 암호화는 대다수에게 비현실적이며, 전송·저장 암호화가 현실적인 보호책이라고 주장합니다.
이메일 서비스 패스트메일의 최고제품책임자 닐 젠킨스가 2025년 12월에 쓴 글입니다. 그는 암호화 방식을 고르기 전에 무엇을 막을지부터 정하라고 권하며, 방식별 효과와 대가를 정리했습니다.
왜 중요한가
- '암호화'라는 말로 묶이던 방식들이 각각 어떤 위협을 막고 못 막는지 가르는 기준을 줍니다.
- 일반 사용자의 현실적 위협은 도청보다 계정 탈취와 피싱이므로, 암호화 강도만으로 메일 서비스를 고르기 어렵습니다.
- 제로 액세스와 종단간 암호화를 택하지 않은 메일 업체가 그 이유를 직접 밝힌 글입니다.
핵심 내용
- 종단간 암호화는 키를 배포할 기반이 없고 스팸 검사·서버 검색과 충돌해, 민감한 대화에는 Signal 같은 메신저를 권했습니다.
- 제로 액세스 암호화(업체도 복호화할 수 없는 방식)는 내부자 위험을 줄이지만, 비밀번호 복구와 검색, 업체 이전이 어려워집니다.
- 저장 암호화는 드라이브 도난에 대비하지만, 키를 업체가 쥐고 있어 법원 명령이 오면 복호화해 넘길 수 있습니다.
- 서버 간 전송의 기본인 기회적 TLS(상대가 지원할 때만 암호화)는 공격자가 평문 전송으로 되돌릴 수 있습니다.
- 패스트메일은 장애 위험을 이유로 DANE(DNS에 인증서 정보를 게시하는 방식)보다 MTA-STS(암호화 요구를 선언하는 정책)를 택했습니다.
HN 반응
- 패스트메일이 발신 메일에 MTA-STS를 강제하지 않는다는 점검 결과와, 인증서 검증을 강제해도 8년간 문제가 드물었다는 경험담이 나왔습니다.
- Signal과 WhatsApp은 암호화가 자동이라는 비교를 두고, 키 검증이 어렵고 실제 암호화를 증명할 수 없다는 비판과 과장이라는 반론이 갈렸습니다.
이 글은 WKD[1](Web Key Directory)를 언급하지 않았습니다. WKD는 Proton Mail이 지원하고, "신뢰 그물"에 의존하지 않으며, 보내는 이메일을 매끄럽게 PGP로 암호화할 수 있게 해 줍니다. 이게 어떻게 동작하는지, 그리고 얼마나 성가셔질 수 있는지는 여기 예시가 있습니다[2].
[1] https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/
[2] https://matduggan.com/why-cant-my-mom-email-me/
이메일 종단간 암호화에 관한 이 글에 이런 대목이 있습니다.
Signal을 대상으로 한 사용성 연구[1]에서 컴퓨터공학 전공 학생 28명 중 21명이 안전한 종단간 암호화 연결을 맺고 유지하는 데 실패했습니다. 거기에는 상충 관계가 있어 보입니다. 사용성이든 보안이든 하나는 얻어도, 둘을 동시에 얻을 수는 없는 겁니다.
[1] When SIGNAL hits the Fan: On the Usability and Security of State-of-the-Art Secure Mobile Messaging https://www.ndss-symposium.org/wp-content/uploads/2018/03/09-when-signal-hits-the-fan-on-the-usability-and-security-of-state-of-the-art-secure-mobile-messaging.pdf
이 논문은 2016년 거예요. 그 뒤로 Signal의 UX는 여러모로 엄청나게 좋아졌고요.
오히려 지금이 더 나빠졌다고 볼 여지도 있습니다. Signal은 나와 상대방의 안전 번호(safety number)를 하나의 아주 큰 숫자로 합쳤습니다[1]. 이제 숫자 하나가 상대방의 신원을 나타내지 않기 때문에 직관성이 떨어졌습니다.
최근 Signal은 신원 관리의 사용성이 형편없어서 여러 문제를 겪고 있습니다[2].
[1] Safety number updates https://signal.org/blog/safety-number-updates/
[2]
A Third Party Breached The Intercept’s Signal Tip Line and Has Been Soliciting Whistleblowers https://www.dropsitenews.com/p/intercept-signal-tip-line-breach-hack
Twilio Incident: What Signal Users Need to Know https://support.signal.org/hc/en-us/articles/4850133017242-Twilio-Incident-What-Signal-Users-Need-to-Know
Russian State-Backed Hackers Intensify Attacks on Signal Messenger Accounts https://thecyberexpress.com/signal-attacks-russian-fackers-target/
End to End Encrypted Messaging in the News: An Editorial Usability Case Study (제가 쓴 글) https://articles.59.ca/doku.php?id=em:sg
결과를 많이 과장하신 것 같습니다.
"... 이 연구는 사용자가 SIGNAL 프로토콜에 대한 중간자 공격을 탐지하고 막을 수 있는지 평가한다. 연구 결과, 대다수 사용자는 사용성 문제와 불완전한 멘탈 모델 때문에 검증 목적으로 대화 상대와 키를 제대로 비교하지 못했다. 따라서 사용자는 오늘날 보안 메시징 앱의 핵심 인프라, 즉 암호화 키를 교환해 주는 중앙 서비스에 대한 공격에 당할 가능성이 매우 높다."
실제 결과를 그대로 설명하면 안 되나요? 대부분의 Signal 사용자는 중간자 공격의 표적이 아니고, 아무 노력이나 고민 없이도 안전한 종단간 연결을 맺습니다.
하지만 최종 목표는 암호화 연결만 허용하는 것일 텐데, 그때가 되면 이 말은 더 이상 맞지 않습니다. 인증서를 검증하지 않으면 오히려 전환이 늦어질 수 있다고 봅니다. 멀쩡해 보이는 연결이 알고 보니 아닐 수 있는데, 지금은 그 오류가 가려져 있을 뿐이니까요.
저는 이메일을 직접 호스팅하는데, 보낼 때마다 암호화를 강제하고 싶다는 게 이유 중 하나입니다. 제 서버는 MTA-STS 사용 여부와 상관없이 대상 MX의 인증서를 검증합니다. 인증서가 유효하지 않으면 전송이 실패하고, 목적지(또는 중간자)가 STARTTLS를 다운그레이드하거나 제거해도 역시 실패합니다.
8년 동안 STARTTLS를 거부하는 서버는 하나도 못 봤고, 유효하지 않은 인증서는 딱 두 번 봤습니다. 두 경우 모두 인증서는 유효한 CA가 발급했고 만료되지도 않았지만 호스트 이름이 틀려 있었습니다. 둘 다 오래된 DNS 레코드 때문이었고, 하나는 제가 알리자마자 고쳐졌으며 다른 하나는 몇 달 뒤에 저절로 해결됐습니다.
그런데 그 대상 MX가 공격자의 통제 아래 있지 않다는 건 어떻게 아시나요? 수신자가 도메인에 DNSSEC을 적용했거나 MTA-STS 정책을 게시하지 않았다면 확실히 알 방법이 없습니다.
DNSSEC/DANE 설정 덕분에 유효한 자체 서명 인증서와, 신뢰할 수 있는 CA가 발급한 인증서는 얼마나 자주 보이나요? 2년 전에 확인했을 때 상위 1,000개 도메인의 99.3%가 STARTTLS를 지원했고 94.1%가 CA가 발급한 TLS 인증서를 썼습니다. 수치는 계속 나아지고 있을 것 같지만 아직 100%는 아니라고 생각합니다.
저도 직접 호스팅합니다. 최소한의 smtp 서버에 TLS도 없이, 이메일을 직접 기본 방식으로 전달만 합니다. DNS 패거리한테는 돈도 안 냅니다. IP 리터럴(mailbox@[x.x.x.x], 그리고 mailbox@[ipv6:...])을 쓰거든요. smtp RFC를 보세요. 이메일 쪽 사람들은 프로토콜이 DNS나 암호화에 강하게 종속되지 않게 할 만큼 똑똑했습니다.
저는 CA 체계를 믿지 않습니다. 이메일 내용을 암호화한다면, 직접 만난 사람이 어떤 식으로든(QR 코드?) 얼굴을 보고 공개 키를 건네줬을 때뿐일 겁니다. 정말 중요한 내용은 어차피 smtp로 보내지 않고, 표준 암호를 변형해서 미리 공유한 키를 쓸 겁니다.
그래도 IP를 위임받는 데는 누군가에게 돈을 내시잖아요? 아니면 직접 ASN을 갖고 BGP도 직접 운영하시나요?
아니요. "선진국"인 우리나라에서는 일부 가정용 인터넷 사업자가 SMTP 포트가 필터링되지 않은 고정 IPv4와 고정 IPv6 프리픽스(보통 /64인데, 침해당했을 때 이메일 주소나 호스팅 IP를 바꾸기에 아주 편합니다. IPv6 리터럴 이메일 주소를 쓴다면요)를 제공합니다. 다만 저는 직접 호스팅에 IPv4는 이제 거의 안 씁니다. 여기서는 IPv6가 아주 오래전부터 거의 모든 사람에게, 아니 모바일 인터넷까지 포함해 모든 사람에게 보급돼 있거든요.
제 IPv4가 "보안" 업계에서 침해된 것으로 알려진 IP들의 분산 포트 스캔 표적이 된다는 것도 압니다. 제 인터넷 사업자의 "보안" 팀도 알고 있을 테고, '대처하는 중'일 거라고 짐작합니다... (IP 차단 이상의 조치일 테고 당국까지 개입하게 되겠죠...).
FTTH(8GB), 고정 IPv6, 고정 IPv4에 SMTP 포트 개방, 한 달에 30달러쯤(수백만 명이 쓰는 망입니다).
그럼 이제 ISP를 옮기거나 바꾸려면 이메일 주소도 바꿔야 한다는 거네요. 엄청 불편해 보입니다. 게다가 ISP가 언제든 요금제를 바꿀 수도 있고요.
그리고 결국 IP를 위임받는 비용을 ISP에 내고 있는 건 맞습니다. ISP 요금제에 묶여 있을 뿐이죠.
임시 상태는 꼬리가 길게 이어지는 법입니다. v6 전환을 보세요. 우리는 당분간 듀얼 스택으로 갈 테고, 보안 메일 전송도 아마 아주 오랫동안 부분적으로만 도입돼 있을 거라고 생각합니다.
Google은 일방적으로 강제할 수 있는 위치에 충분히 있습니다.
이미 하고 있습니다. 아쉽게도 대량 발송자에게만 적용되지만요.
https://support.google.com/mail/answer/81126
그 문서를 보면 수신 메일 전체에는 요구하지만 발신 메일까지는 아직 적용하지 않는다는 뜻입니다.
Google은 IP 리터럴 이메일 주소를 차단합니다(SPF보다 강력하니 DMARC에 포함돼야 합니다).
이메일 암호화를 잘 개괄한 글이지만, Fastmail이 실제로 지원하는 내용은 다루지 않아서 오해를 부를 수 있다고 봅니다.
Fastmail은 발신 메시지에 MTA-STS를 강제하지 않습니다. 방금 여기서 확인했습니다( https://email-security-scans.org/view/jktrld5e73b2dyxz0h1swutlre5vjt ). 쓰시는 이메일 제공업체가 어떤지는 https://email-security-scans.org 에서 비교해 볼 수 있습니다.
Fastmail은 수신 메시지에는 MTA-STS를 지원합니다... 어느 정도는요. 수신 MTA-STS를 쓰려면 이메일 제공업체가 신뢰할 수 있는 인증 기관이 발급한 TLS 인증서를 써야 하는데, Fastmail은 그렇게 합니다. 게다가 "받는 사람 주소"의 도메인이 DNS 레코드 몇 개로 MTA-STS를 활성화해야 합니다. Fastmail은 이 설정 방법에 대한 문서를 제공하지 않지만, 스스로 알아낸 사람들이 꽤 쓰고 있습니다. Fastmail을 쓰는 도메인 중 약 0.2%가 수신 MTA-STS를 enforce로 쓰는 것으로 보입니다.
이는 Protonmail(약 0.2%)과 비슷하고, Outlook(약 0.1%)과 Google(0.1% 미만)보다는 높습니다. 기술에 밝은 사람들 사이에서 Fastmail이 인기라는 사실이 반영된 것 같습니다.
Fastmail이 MTA-STS 지원 여부와 설정 방법을 분명하게 문서화하고, 커스텀 도메인 대시보드에서 MTA-STS를 검증해 주는 식으로 개선하면 좋겠습니다. MTA-STS 정책 호스팅을 추가하려는 듯한데, 아주 희망적인 신호입니다. 다만 아직 문서에는 없으니 내부에서 테스트 중인 것 같습니다.
그렇긴 해도 저는 Fastmail을 몇 년째 아주 만족하며 쓰고 있고, 추천합니다.
최근에 계속 소통 상황을 공유해야 하는 큰 그룹에 암호화에는 age 키를 쓰고, 지시 사항은 스레드에서 큰 틀로만 논의하자고 제안했습니다. 이러면 모두가 대체로 상황을 알고 있으면서, 기술 담당자들은 민감한 페이로드를 첨부 파일로 주고받을 수 있습니다. 민감한 데이터가 저장될 때나 전송될 때나 보호되고, 논의는 모두에게 익숙한 채널에서 이어집니다.
S/MIME을 처음 써 봤습니다. 많은 메일 제공업체와 소프트웨어가 S/MIME을 기업용 라이선스 뒤에 숨겨 놓았는데, 1년에 이메일 두어 통 때문에 그럴 순 없었어요. Thunderbird 팀과 OpenSC 프로젝트에 정말 감사합니다.
Forward Email은 쓰지 않고 있는 메일함에 대해 Fastmail보다 강한 보호를 제공하고, 진짜 DANE과 선택형 PGP도 지원합니다.
이건 지나치게 자신만만한 주장입니다. WhatsApp이나 Signal의 실제 배포용 소비자 빌드가 정말로 뭔가를 암호화한다는 걸 확정적으로 증명한 사람은 아무도 없으니까요 (참고: 사용자가 직접 컴파일한 Signal 빌드는 이와 무관합니다).
WhatsApp에 대한 기존 리버스 엔지니어링 논문은 암호화 기본 요소와 함수 표지가 있다는 것만 확인할 뿐입니다. 사용자 메시지가 실제로 실행 중에 암호화·복호화되는지는 증명하지 못했고, 빌드 안에 암호화 우회 수단이나 비밀 스위치가 없다는 보장도 하지 못합니다.
사실관계를 엄밀하게 지키려면 필자는 대신 완전히 재현 가능한 빌드를 공개하는 Delta Chat과 SimpleX Chat을 언급했어야 합니다.
이건 지나치게 자신만만한 주장입니다. WhatsApp이나 Signal의 실제 배포용 소비자 빌드가 정말로 뭔가를 암호화한다는 걸 확정적으로 증명한 사람은 아무도 없으니까요 (참고: 사용자가 직접 컴파일한 Signal 빌드는 이와 무관합니다).
AI가 엄청나게 발전했으니 Signal을 디컴파일해서 소스와 비교하거나, WhatsApp을 리버스 엔지니어링시켜서 백도어 같은 게 있는지 보는 건 꽤 쉬운 일일 겁니다.
Delta Chat을 알려 주셔서 고맙습니다. 이제 꼭 써 보고 싶네요.
WhatsApp이 암호화돼 있다는 건 우리가 안다고 생각해요... 사용자가 그렇게 많으니, 지금쯤이면 나쁜 놈들이 WA로 소통하다 잡혔다는 사실이 법정 사건(특히 형사 사건)을 통해 드러났을 테니까요.
수사기관의 영장에 뚫리는 건 흔히 Google이나 Apple 키로 서명돼 Google이나 Apple에 업로드된 백업입니다. 지금도 그 구멍을 막으려면 백업에 종단간 암호화를 직접 켜야 한다고 하더군요.
저는 수동 백업만 합니다. 하지만 제 요지는, 데이터가 수사기관에 접근 가능하다면 대부분 봉인이 풀리는 형사 사건들을 통해 이미 알려졌을 거라는 겁니다. 제가 아는 한 그런 사례는 없습니다. 물론 저는 마크 리저드맨(Mark Lizardman)을 믿는 마지막 사람이겠지만요.
(2025)
Fastmail이 CA 인증서를 제공한다면, 저는 Fastmail을 쓸 때마다 모든 CA 인증서를 제거하고 Fastmail의 CA 인증서만 로드한 별도의 브라우저 인스턴스나 메일 클라이언트를 따로 실행할 겁니다.
이런 행동을 하느냐 마느냐, 그리고 그 결과로 가능해지는 기능이 "모범 사례 합의를 따르는" 보안 팀과 상위 단계의 보안 팀을 가르는 차이입니다.
다른 조직에 대해서도 그렇게 하시나요?
저희는 이 방안을 진지하게 검토해 본 적이 없습니다. 실제로 관심을 갖고 그렇게 할 사람의 시장 규모는 오차 범위에 불과하고, 사용자 쪽(선생님 개인이 아니라 고객 전반)과 저희 쪽(제공업체 전반입니다. DNSSEC이 수년간 겪은 실패를 보세요) 모두에서 사람의 실수가 날 확률도 꽤 높기 때문입니다.
지금처럼 우리 모두가 eMudhra 하나만 뚫리면 위험해지는 상황에 비하면 분명 이상적이긴 합니다. 하지만 비례적이고 합리적이며 실행 가능한 길은 보이지 않습니다. 이 분야에서 Fastmail은 선두 주자가 아닙니다. 저희의 핵심 전문 분야가 아니니까요. 말씀하신 "모범 사례 합의"를 따르는 이유는, 그것이 현실적인 위협으로부터 대다수 사람을 그들이 따라갈 수 있는 방식으로 실제로 지켜 주기 때문입니다.