이메일 암호화는 하나가 아니에요
“이메일도 암호화되나요?”라는 질문에 정확히 답하기는 생각보다 어려워요. 이메일 암호화는 한 가지가 아니라 여러 층으로 나뉘어 있고, 층마다 막아주는 위협이 전부 다르거든요. 최근 메일 서비스 Fastmail이 블로그에 이메일 암호화를 설명하는 글을 올렸는데요, 이 기회에 이메일이 보내는 사람에게서 받는 사람에게 가는 동안 어느 구간이 보호되고 어느 구간이 무방비인지 차근차근 정리해볼게요.
이메일은 어떻게 배달되냐면
먼저 이메일이 지나가는 길부터 알아야 해요. 메일 앱에서 보내기를 누르면 메일은 먼저 내 메일 서버로 가요. 그 서버가 받는 사람의 메일 서버를 찾아서 SMTP라는 프로토콜로 넘겨주고, 받는 사람은 자기 메일 서버에서 IMAP 같은 방식으로 메일을 가져와요. 우편으로 치면 우리 동네 우체국, 상대방 동네 우체국, 상대방 집 우편함을 차례로 거치는 셈이에요. 암호화도 이 구간마다 따로 따져봐야 해요.
1층: 전송 구간 암호화 (TLS)
가장 기본은 구간마다 통신을 암호화하는 TLS예요. 웹사이트의 HTTPS와 같은 기술이에요. 메일 앱과 메일 서버 사이는 요즘 거의 다 TLS로 보호돼요.
문제는 서버와 서버 사이예요. SMTP는 원래 평문 프로토콜이라, 나중에 STARTTLS라는 방식으로 “지금부터 암호화할까?”라고 협상하는 기능이 덧붙었어요. 그런데 이 협상은 암호화되기 전에 오가기 때문에, 중간에 있는 공격자가 “나는 암호화 지원 안 해”라고 응답을 바꿔치기하면 메일이 평문으로 전송될 수 있어요. 이걸 다운그레이드 공격이라고 해요.
그래서 나온 게 MTA-STS와 DANE이에요. MTA-STS는 받는 쪽 도메인이 “우리 서버로 보낼 땐 반드시 TLS를 쓰고 이 인증서를 확인해”라는 정책을 HTTPS로 공개하는 방식이에요. DANE은 같은 정보를 DNSSEC으로 서명된 DNS 레코드에 담아요. 둘 다 암호화가 안 되면 아예 보내지 말라고 강제할 수 있어요.
다만 TLS는 이동 중인 데이터만 보호한다는 걸 기억해야 해요. 메일 서버에 도착한 메일은 서버가 얼마든지 읽을 수 있는 상태예요.
2층: 저장 데이터 암호화
메일 서버는 받은 메일을 디스크에 저장하고, 대부분의 서비스는 이 디스크를 암호화해요. 덕분에 누가 데이터센터에서 하드디스크를 통째로 훔쳐가도 메일을 읽을 수 없어요. 하지만 서버가 정상적으로 동작하려면 메일을 읽을 수 있어야 하니까, 서비스 운영자나 서버를 장악한 공격자는 이 암호화로 못 막아요.
3층: 종단간 암호화 (PGP, S/MIME)
정말로 보내는 사람과 받는 사람만 읽게 하려면 종단간 암호화(E2EE)가 필요해요. 이메일에서는 PGP(OpenPGP)와 S/MIME가 대표적이에요. 받는 사람의 공개키로 본문을 암호화하면, 그 사람의 개인키가 없는 한 아무도 못 읽어요. 중간 서버들은 내용을 알 수 없는 데이터 덩어리를 전달하기만 하는 거죠.
그런데 이메일 E2EE가 널리 쓰이지 못하는 이유가 있어요. 첫째, 키 관리가 어려워요. 상대방 공개키를 믿을 수 있는 방법으로 받는 것도, 개인키를 잃어버렸을 때 대처하는 것도 일반 사용자에게는 너무 어렵거든요. 둘째, 메타데이터는 숨겨지지 않아요. 보낸 사람, 받는 사람, 시간 같은 헤더는 배달을 위해 평문으로 남고, 제목도 대부분 그대로 노출돼요. 셋째, 편의 기능이 깨져요. 서버가 내용을 못 읽으니 서버 쪽 검색이나 스팸 필터링이 어려워져요. 넷째, 웹메일에서는 암호화 코드 자체를 서버가 내려주기 때문에, 서버를 믿지 않는다는 E2EE의 전제와 부딪쳐요.
업계 맥락
그래서 업계는 크게 두 방향으로 나뉘어요. 하나는 Proton Mail처럼 처음부터 E2EE를 중심에 두고, 같은 서비스 사용자끼리는 자동으로 암호화하는 쪽이에요. 다른 하나는 Gmail이나 Fastmail처럼 전송 구간과 저장 데이터 보호를 탄탄히 하되, E2EE를 기본으로 제공하지는 않는 쪽이고요. 정말 민감한 대화라면 Signal처럼 처음부터 E2EE를 전제로 만든 도구를 쓰는 게 낫다는 의견도 많아요. 이메일은 수십 년 전 설계 위에 보안을 덧붙여온 시스템이라 근본적인 한계가 있거든요.
한국 개발자에게 주는 시사점
서비스에서 메일을 보내는 개발자가 헷갈리기 쉬운 게 있어요. SPF, DKIM, DMARC는 암호화가 아니라 인증이에요. 이 메일을 정말 우리 도메인에서 보냈는지 증명해줄 뿐, 내용을 숨겨주지는 않아요. 2024년부터 Gmail과 Yahoo가 대량 발송자에게 이 설정을 요구하면서 많이들 챙기셨을 텐데요, 여기에 더해 자사 도메인에 MTA-STS를 설정하고 TLS-RPT로 전송 실패 리포트를 받아보는 것까지 해두면 좋아요.
비밀번호 재설정 링크, 인증번호, 개인정보가 담긴 명세서를 메일로 보낼 때는 중간 서버가 내용을 읽을 수 있다고 가정하고 설계해야 해요. 링크는 만료 시간을 짧게 잡고 한 번만 쓸 수 있게 만들고, 민감한 문서는 메일 본문에 넣지 말고 로그인한 뒤에 확인하도록 하는 게 안전해요.
마무리
한줄 정리: 이메일 암호화는 전송 구간 TLS, 저장 데이터 암호화, 종단간 암호화의 세 층으로 나뉘고, 층마다 막아주는 위협이 달라요.
여러분 서비스의 메일 도메인에는 MTA-STS나 DMARC가 설정돼 있나요? 이메일 종단간 암호화가 대중화되는 날이 올 거라고 보세요?
🔗 출처: Hacker News