주요 이메일 제공업체는 모두 메일이 암호화된다고 주장한다. 이것이 실제 어떤 의미인지 깊이 파헤쳐 보았다. 한국에서 인기가 높은 Gmail, Outlook, iCloud, 네이버, 다음, 카카오 등 6개 메일함을 대상으로 테스트를 진행했다.
6곳 모두 TLS를 사용했지만, TLS 다운그레이드 공격으로부터 이를 보호하는 곳은 2곳에 불과했다.
무료 계정에서 S/MIME을 지원하는 곳은 단 1곳뿐이었다.
더 심각한 점은, 3곳은 사용자가 보내는 모든 이메일에 IP 주소를 노출한다는 사실이다!
이 글에서는 이메일 암호화의 두 가지 주요 유형과 각 메일함을 테스트한 방법, 그리고 결과가 어떠했는지 살펴본다.
이메일 암호화의 두 가지 종류
전송 암호화(TLS)는 메시지가 한 메일 서버에서 다음 메일 서버로 이동하는 동안 메시지를 보호한다. 각 서버는 메시지가 도착하면 복호화하므로, 발신자와 수신자 측 서버 모두 평문 이메일 메시지를 읽을 수 있다.
종단간 암호화(End-to-end encryption)는 메시지 자체를 보호한다. 널리 사용되는 표준 기술은 S/MIME이다. 발신자는 수신자의 공개 인증서로 메시지를 암호화한다. 이 메시지를 복호화하는 유일한 방법은 수신자의 개인키를 사용하는 것이며, 개인키는 보통 수신자의 기기에만 보관된다.
S/MIME은 메시지에 서명하는 데도 사용할 수 있다. 서명은 누가 메시지를 보냈는지, 전송 중에 내용이 변조되지 않았는지를 증명하는 데 쓰인다.
테스트 방식
- Amazon SES를 통해 12개의 메시지를 발송했다. 각 메일함마다 S/MIME 서명 메시지 1개와 S/MIME 암호화 메시지 1개를 보냈다.
- 인증서는 직접 생성한 테스트용 인증 기관(CA)에서 발급받았다. 어떤 기기에서도 이 CA를 신뢰하지 않으므로, 서명을 검증하는 메일함이라면 발신자에 대한 경고를 표시해야 한다. 이는 의도된 상황이다.
- 각 계정에서 자체 Google Workspace 주소로 이메일을 1건씩 발송했다. 각 서비스가 보내는 메일을 어떻게 암호화하는지, 그리고 헤더에서 발신자에 대해 어떤 정보가 드러나는지 확인하기 위함이다.
- 각 서비스의 MTA-STS 및 DANE 레코드를 확인했다. 이는 다른 서버에 암호화 적용이 필수임을 알리는 메커니즘이다.
대부분의 메일 서버는 메시지 헤더에 사용한 TLS 버전을 기록한다. 이 헤더 정보들을 다음 섹션의 근거로 활용한다.
서버 간 전송: 뒤처지는 다음과 카카오
| 메일함 | 수신 | 발신 |
|---|---|---|
| Gmail | TLS 1.3 | Google 내부 처리 |
| Outlook | TLS 1.3 | TLS 1.3 |
| iCloud | TLS (버전 미기록) | TLS 1.3 |
| 네이버 | TLS 1.3 | TLS 1.3 |
| 다음 | TLS 1.2, 순방향 비밀성 미지원 | TLS 1.3 |
| 카카오 | TLS 1.2, 순방향 비밀성 미지원 | TLS 1.3 |
다음과 카카오는 Hanmail이 언급된 헤더를 공유한다는 점에서 동일한 메일 시스템으로 메일을 수신하는 것으로 보인다.
테스트 메시지는 TLS_RSA_WITH_AES_128_CBC_SHA256 암호화 방식을 사용하는 TLS 1.2를 통해 다음과 카카오에 전달되었다. 이 암호화 방식은 순방향 비밀성(forward secrecy)을 지원하지 않는 것으로 알려져 있다. 즉, 누군가 오늘 트래픽을 기록해 두고 나중에 서버의 개인키를 확보하면 과거의 모든 기록을 복호화할 수 있다. TLS 1.3에서는 이러한 이유로 해당 방식을 제거했다.
RFC 8446 §1.2: "고정형 RSA 및 디피-헬만(Diffie-Hellman) 암호화 스위트가 제거되었으며, 이제 모든 공개키 기반 키 교환 메커니즘은 순방향 비밀성을 제공한다."
동일한 발신자가 Gmail, Outlook, 네이버로 보낸 메일은 TLS 1.3을 통해 전달되었으므로, 이전 암호화 방식을 적용한 것은 다음 측이다. 다음과 카카오 역시 메일을 보낼 때는 TLS 1.3을 사용하므로, 수신 서버만 뒤처져 있는 것으로 보인다.
MTA-STS 보급 현황: TLS 다운그레이드를 차단하는 곳은 Gmail과 Outlook뿐
메일 서버 간의 암호화는 기본적으로 기회주의적(opportunistic)이다. 네트워크 경로상에 있는 공격자가 수신 서버의 TLS 지원 제안을 삭제하면, 발신 서버는 오류 없이 평문으로 메일을 전달하게 된다.
이러한 다운그레이드 공격을 방지할 수 있는 두 가지 표준 규격이 있다.
- MTA-STS: HTTPS를 통해 정책을 게시하여, 유효한 TLS 연결을 확보할 수 없을 경우 발신 측이 메일 전달을 거부하도록 안내한다.
- DANE: DNSSEC로 서명된 DNS에 메일 서버의 인증서를 TLSA 레코드로 게시한다.
각 서비스 제공업체의 모든 메일 서버에 대해 두 레코드를 모두 조회했다.
| 메일함 | MTA-STS | DANE | 다운그레이드 보호 여부 |
|---|---|---|---|
| Gmail | Enforce (강제 적용) | 없음 | 예 |
| Outlook | Enforce (강제 적용) | 없음 | 예 |
| iCloud | 없음 | 없음 | 아니오 |
| 네이버 | 없음 | 없음 | 아니오 |
| 다음 | 없음 | 없음 | 아니오 |
| 카카오 | 없음 | 없음 | 아니오 |
6곳 모두 DANE을 게시하지 않았다. Gmail과 Outlook은 적절한 MTA-STS 정책을 사용하여 TLS를 강제 적용하고 있다.
iCloud, 네이버, 다음, 카카오는 MTA-STS 정책을 게시하지 않으므로, 해당 메일 서버로 연결되는 네트워크 경로를 제어하는 누군가에 의해 이메일이 평문으로 강제 전송될 수 있다.
무료 계정에서의 S/MIME 지원: iCloud가 유일
모든 S/MIME 메시지의 원본을 다운로드하여 OpenSSL로 검증했다. 6개 서비스 제공업체 모두 서명과 암호화된 콘텐츠를 손상 없이 전달했다.
그러나 무료 계정에서 S/MIME을 지원하는 경우는 거의 없다.
| 메일함 | 무료 계정 S/MIME 지원 여부 |
|---|---|
| iCloud | 예: iCloud Mail에서 서명을 검증하며, Apple Mail에서 설치된 인증서로 복호화 가능 |
| Outlook | 아니오: 웹용 Outlook에서는 직장 또는 학교 계정에만 제공 |
| Gmail | 아니오: Google에서는 Workspace Enterprise Plus, Frontline Plus 및 Education 버전에만 제공 |
| 네이버, 다음, 카카오 | 아니오: 서명은 smime.p7s 첨부파일로, 암호화된 메시지는 smime.p7m 첨부파일로 표시됨 |
개인정보보호 미흡: IP 주소를 노출하는 네이버, 다음, 카카오
네이버에서 발송한 이메일에는 메일을 보낸 컴퓨터의 공인 IP 주소가 담긴 X-Originating-IP 헤더가 포함되어 있었다. 다음과 카카오 역시 X-Originating-IP 헤더와 첫 번째 Received 헤더에 동일한 IP 주소를 포함시켰다.
Received: from 220.64.108.39 ([203.0.***.***]) by skadi-sender ...
X-Originating-IP: [203.0.***.***]
위 예시에서는 IP 주소를 가렸지만, 해당 서비스 제공업체들은 IP 주소를 가림 없이 그대로 전송한다.
IP 주소는 발신자의 ASN(자율 시스템 번호), 로컬 네트워크, 나아가 대략적인 위치까지 파악하는 데 악용될 위험이 있다.
Gmail과 Outlook의 헤더에는 해당 서비스의 서버 주소만 표시된다. iPhone Mail 앱에서 발송한 iCloud 이메일의 헤더에는 Apple 주소가 표시되었다.
민감한 메시지를 보내야 할 때는 어떻게 해야 할까?
S/MIME은 메일 클라이언트의 기능이다. 키가 사용자의 기기에 저장되어 있으므로, S/MIME을 지원하는 클라이언트를 사용하면 IMAP을 통해 네이버나 다음을 포함한 모든 제공업체의 메일을 복호화할 수 있다.
- S/MIME을 지원하는 메일 클라이언트를 사용한다. 예시: iPhone 및 Mac의 Apple Mail, Thunderbird, Proton, Microsoft 365 업무용 계정의 Outlook, Google 유료 플랜.
- Google Workspace의 경우: S/MIME을 쓰려면 Enterprise Plus, Frontline Plus 또는 Education 버전이 필요하며, 호스팅 방식이다. 즉, 개인키가 Gmail에 업로드된다.
- PGP를 지원하는 메일 클라이언트를 사용한다.
- PGP를 사용해 메시지의 민감한 부분을 직접 암호화한다. PGP로 암호화된 암호문을 첨부파일로 첨부하거나 메시지 본문에 넣을 수 있다.
- 그렇지 않다면 민감한 내용을 메일 본문에 작성하지 않는다. 종단간 암호화가 적용되지 않은 메시지는 메일 서비스 제공업체가 전부 읽을 수 있다.
smime.p7s 첨부파일이 들어 있는 이메일을 받고 대체 무엇인지 궁금했던 적이 있는가?
참고 자료
- IETF — RFC 8551: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification (2019년 4월)
- IETF — RFC 7672: SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) (2015년 10월)
- IETF — RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (2018년 8월)
- Google Workspace 관리자 도움말 — 메시지 암호화를 위한 호스팅된 S/MIME 사용 설정
- Google Workspace 관리자 도움말 — 호스팅된 S/MIME FAQ
- Microsoft 지원 — S/MIME 암호화를 사용하도록 Outlook 설정
- Apple 지원 — iOS용 메일 앱에서 S/MIME을 사용하여 암호화된 메시지 보내기 및 받기
- Panke — 실제 환경에서의 MTA-STS 정책 적용 현황 (2026년 9월 22일)
- Panke — 이메일 서비스 6곳의 S/MIME 및 TLS 테스트 (자체 측정, 2026년 9월 23일)
Instagram