전기전자/정보통신

Nikkei Network_2022.7 특집 (p34-40)

메일은 위험하다
10통에 1통이 도청 리스크

탄생한지 반세기 이상이 경과한 지금까지도 비즈니스 툴로서 널리 사용되고 있는 전자 메일. 기업간의 기밀 정보 교환 등에도 사용되고 있다. 그러나 메일은 이용자가 생각하는 것만큼 안전하지 않다.

Part 1. 위험한 현재 상황

구글에 따르면 2022년 2월 10일부터 5월 11일 사이에 구글의 메일 서비스 ‘Gmail’에서 전송 메일의 18%, 수신 메일의 12%가 통신 경로가 암호화되어 있지 않았다고 한다. 즉, 주고받는 메일의 10% 이상이 도청 리스크에 노출되어 있었다.

여기서 말하는 ‘통신 경로가 암호화되어 있지 않다’라는 것은, Gmail의 서버와 메일 서버 간에 안전한 통신 방법(프로토콜)이 사용되고 있지 않다는 의미다. 예를 들면 전송 메일의 경우는 Gmail의 서버와 전송 측 메일 서버 간 통신 중 18%에서 안전한 프로토콜이 사용되지 않고, 메일이 암호화되어 있지 않았다.

일본 국내 사태가 더 심각한 것 같다. 인터넷 이니셔티브(IIJ)가 자사의 메일 서비스로 2020년 10월에 조사한 결과에 따르면, 전송 메일의 30.4%, 수신 메일의 37.5%가 경로를 암호화하지 않았다.

-- 표준으로는 암호화되지 않는다 --
구글이 지적한 것은 메일 서버 간 통신 경로의 리스크이지만 실제로는 이외에도 위험한 통신 경로가 있다. 클라이언트와 서버 간의 통신 경로이다.

메일 방식에는 크게 메일 클라이언트 방식과 웹 메일 방식의 2종류가 있다. 전자는 클라이언트에 전용 소프트웨어(메일 클라이언트)를 이용하는 방식이고, 후자는 웹 브라우저를 클라이언트로 하는 방식이다. 2종류 모두에서 암호화해야 할 곳은 클라이언트와 메일 서버 간, 메일 서버와 메일 서버 간의 2곳이다.

메일 클라이언트 방식에서는, 메일 클라이언트로부터 메일 서버로의 메일 전송이나, 메일 서버 간 송수신에는 SMTP(Simple Mail Transfer Protocol)라는 프로토콜이 사용된다. 그리고 메일 클라이언트가 메일 서버로부터 메일을 수신할 때에는 POP(Post Office Protocol)나 IMAP(Internet Message Access Protocol)라는 프로토콜이 사용된다.

이것들은 모두 표준에서는 암호화 기능을 갖추고 있지 않다. 때문에 후술하는 암호화 시스템을 도입하지 않으면 메일은 경로를 암호화하지 않고 전송된다. 실제로 모두에서 말한 것처럼 암호화에 대응하지 않는 메일 서버가 적지 않게 존재하기 때문에 비암호화 경로가 남게 된다.

웹 메일 방식도 메일 클라이언트 방식과 마찬가지로 메일 서버 간 통신에는 SMTP를 사용한다. 이 때문에 암호화되지 않는 통신 경로가 존재할 가능성이 있다. 다만 클라이언트가 웹 브라우저이기 때문에 웹의 암호화 프로토콜인 HTTPS(HyperText Transfer Protocol Secure)를 표준으로 사용한다. 그래서 암호화 시스템을 별도로 마련하지 않아도 클라이언트와 서버 간 통신은 암호화된다.

-- TLS의 개시 타이밍이 다르다 --
메일 통신의 암호화에는 웹 통신의 암호화와 마찬가지로 TLS(Transport Layer Security)라는 프로토콜을 이용한다. 웹에서 표준적으로 이용되고 있는 암호화 프로토콜인 HTTPS는 HTTP(HyperText Transfer Protocol)라고 하는 프로토콜에 TLS를 조합한 것이다.

메일 통신의 암호화에는 SMTP와 TLS를 조합한다. 조합 방법에는 STARTTLS와 SMTPS(SMTP over TLS)의 2종류가 있다. 양자의 차이는 TLS에 의한 통신을 개시하는 타이밍이다.

STARTTLS에서는 TCP 세션을 확립한 직후에 메일 전송을 위한 SMTP 통신을 개시한다. 그 후 ‘STARTLS’ 커맨드를 전송하고, 상대가 TLS에 대응하고 있는지 확인한다. 대응하고 있는 경우에는 이후의 SMTP 통신을 TLS로 암호화한다. 상대가 TLS 비대응인 경우에는 암호화하지 않고 SMTP 통신을 계속한다.

즉 TLS에 대응하지 않는 상대방에게도 메일을 보낼 수 있기 때문에 도달성이 뛰어나다. 이 때문에 널리 보급되었다.

한편 SMTPS에서는 SMTP에 의한 통신을 시작하기 전에 TLS의 네고시에이션을 개시한다. 그리고 상대가 TLS에 대응하고 있지 않으면 통신을 종료한다. 즉, TLS에 대응하지 않는 상대에게는 메일을 전송할 수 없어 도달성이 낮다. IIJ 네트워크 본부 서비스추진부의 사쿠라바(櫻庭) 시니어 엔지니어는 “메일 서버 간에서 SMTPS는 거의 사용되지 않는다”라고 지적한다.

-- STARTTLS는 '관망 암호화' --
앞에서 말한 바와 같이 STARTLS라면 TLS에 대응하지 않는 상대방에게도 메일을 보낼 수 있다. 이는 큰 장점인 반면 보안 강도를 낮추기도 한다. 메일 경로 상에 TLS에 대응하지 않는 서버가 1대라도 있으면 도청될 위험이 높아진다.

TwoFive의 최고기술책임자(CTO)인 가세(加瀬) 씨는 “상대가 대응하고 있으면 TLS로 통신을 하지만 강제는 아니다. 대응하지 않으면 암호화하지 않고 전송한다. 말하자면 STARTTLS는 ‘형세를 관망하는’ TLS이다”라고 지적한다.

STARTTLS의 약점을 보완하는 시스템도 있다. 그 하나가 MTA-STS(Mail Transfer Agent Strict Transport Security)라는 시스템이다. 이것은 수신 측 메일 서버가 TLS에 관한 정책을 전송 측 메일 서버에 전달하는 시스템이다. 

예를 들면, TLS에 대응하지 않는 상대와는 메일을 주고받고 싶지 않은 경우, 수신 측은 MTA-STS에서 ‘enforce’라는 모드를 설정한다. 전송 측 메일 서버에서는 이 모드를 참조하여 TLS를 사용할 수 없는 상황에서는 메일을 보내지 않도록 한다.

바꿔 말하면, TLS에 의한 암호화를 수신 측이 강제할 수 있게 된다. 이 상대방에게 메일을 보내고 싶은 경우에는 전송 측이 TLS에 대응해야 한다. MTA-STS에 대응하는 메일 서버가 늘어나면 암호화되지 않은 경로를 줄여나갈 수 있을 것으로 보인다.

그러나 MTA-STS는 비교적 새로운 사양이며, 보급에는 아직 시간이 필요하다고 한다. 구현도 그리 쉬워 보이지는 않는다. 다양한 시스템이 마련되어 있지만 인터넷 상의 메일 통신 경로 모두를 암호화하려면 시간이 걸릴 것으로 보인다. 메일을 계속 사용한다면 도청 위험을 어느 정도 허용할 필요가 있다.

Part 2. 메일의 대체

전술한 바와 같이 메일에는 도청의 위험이 있다. 그럼에도 불구하고 계속 사용되고 있다. 메일이 처음 등장했던 반세기 이상 전과는 달리 지금은 다양한 기술과 서비스가 등장하고 있다. 메일을 대체할 기술이나 서비스는 존재하지 않는 것일까?

-- 통신 경로에서는 확실하게 암호화 --
메일을 대체할 후보로 최근 존재감이 커지고 있는 비즈니스 채팅을 꼽을 수 있다. 비즈니스 채팅에서는 클라이언트에 전용 소프트(데스크탑 클라이언트 소프트)나 웹 브라우저를 사용한다. 이러한 클라이언트와 서비스를 제공하는 서버 사이에는 웹의 암호화 시스템인 HTTPS를 사용하고 있다. 때문에 도청의 위험성이 낮다.

웹 메일에서도 클라이언트와 서버 간에는 HTTPS로 접속하기 때문에 도청되기 어렵다. 그러나 서로 다른 조직이 운용하는 메일 서버 간 통신은 암호화된다는 보장이 없다.

한편 비즈니스 채팅에서는 통신이 서비스 사업자에서 완결되므로 클라이언트와 서버 간에만 암호화되어 있으면 안전성이 보장된다. 일반적으로 비즈니스 채팅에서는 서버와 클라이언트 간에 메시지를 암호화했다가 서버에 도달할 때 복호화한다. 그리고 다시 암호화해서 보존한다.

그러나 비즈니스 채팅에는 결점도 있다. 같은 비즈니스 채팅 서비스를 이용하는 상대방과만 메시지를 주고받을 수 있다는 점이다. 이 때문에 사외 사람과 메일을 교환하고 싶은 경우에는 우선 상대방이 이용하고 있는 서비스를 물어볼 필요가 있다. 다른 서비스를 사용하고 있다면 어느 한쪽이 상대의 서비스를 사용해야 하는데, 기업의 보안 정책 등에 의해 허가되지 않는 경우가 있다.

또한 같은 서비스를 이용하고 있는 기업 간에도 어느 한쪽이 외부와의 메일 교환을 제한하고 있는 경우에는 이용할 수 없다. 한편 메일은 사양이 개방적이고 표준화되어 있기 때문에 다른 제품이나 서비스 간 상호운용성이 보장되고 있다. 다른 벤더의 메일 서버 간에도, 다른 클라우드 메일 서비스 간에도 상대방의 메일 주소만 알면 메시지를 전달할 수 있다.

-- 메일 주소가 불가피 --
비즈니스 채팅이 메일을 대체하지 못하는 이유는 또 있다. 메일 주소의 존재이다. 메일 이외에 메시지를 주고받을 수단이 없던 시절, 인터넷 이용자라면 메일 주소를 만드는 것은 당연했다. 그때부터 메일 주소는 인터넷에서 ID로서 기능하고 있다.

예를 들면, EC(전자상거래) 사이트나 SNS와 같은 웹 서비스 계정을 만들 때는 메일 주소를 입력해야 한다. 대부분의 비즈니스 채팅에서도 계정을 만들려면 메일 주소가 필요하다. 메시지를 주고받을 때 더이상 메일을 사용하지 않게 되더라도 메일 주소는 ID로서 계속 사용될 것이다.

-- 메일 자체를 암호화하는 S/MIME --
메일 이외의 수단을 사용하는 것이 아니라 메일 그 자체를 암호화해 안전성을 높이는 아이디어도 있다. 메일 자체를 암호화하면 경로가 암호화되어 있지 않아도 도청 위험을 줄일 수 있다. 이른바 암호화 메일이다. S/MIME(Secure/Multipurpose Internet Mail Extensions)는 암호화 메일의 대표적인 시스템이다.

S/MIME에서는 공통키 암호 방식 및 공개키 암호 방식이라는 암호 방식을 사용한다. 공통키 암호 방식은 같은 키(공통키)를 사용해 암호화와 복호화를 실시한다. 한편 공개키 암호 방식에서는 쌍이 되는 키(비밀키와 공개키)를 사용해 암호화와 복호화를 각각 실시한다.

S/MIME에 의한 암호화 순서는 다음과 같다. 우선 메일 전송자는 수신자의 공개키를 취득한다. 그리고 전자증명서를 사용하여 정말로 수신자의 공개키인지 여부를 검증한다. 그런 다음에 전송자는 공통키를 작성해 메일을 암호화한다. 그리고 수신자의 공개키로 그 공통키를 암호화하고, 암호화한 메일과 함께 수신자에게 보낸다.

그것들을 받은 수신자는 암호화된 공통키를 자신의 비밀키로 복호화. 그리고 그 공통키를 사용해 메일의 암호를 푼다. S/MIME에서는 전송자에게서 온 메일은 암호화된 채로 수신자에게 보내진다. 즉 엔드 투 엔드로 암호화된다. 경로 도중에 메일이 복호되지는 않는다. 때문에 메일을 중계하는 메일 서버 관리자라도 훔쳐볼 수 없다. 보안 강도는 매우 높다.

반면에 도입이나 운용에 비용이 든다. 예를 들면 S/MIME에 필수인 전자증명서의 대부분은 유지에 1인당 연간 수 만엔 단위의 비용이 든다. 가세 씨는 “전송자의 요구로 메일을 암호화하고 싶어하는 경우는 많지만, 수신자에게 S/MIME의 비용은 부담이 된다. 이것이 보급이 잘 되지 않는 이유의 하나일 것이다”라고 지적한다.

또한 엔드 투 엔드로 암호화할 수 있는 것이 단점이 되기도 한다. S/MIME로 암호화된 본문은 경로 상에서 복호가 불가능하기 때문에 도청은 방지할 수 있지만 바이러스 체크를 할 수 없다. 때문에 수신 메일의 바이러스 체크를 필수로 하는 기업에게는 S/MIME를 사용할 수 없다.

-- '적재적소'로 사용한다 --
현재로서는 메일에는 도청의 위험이 뒤따른다. 그러나 비즈니스 채팅이 모든 것을 대체하기는 어렵다. S/MIME에서 메일 보안을 높이는 방법도 있지만, 모든 메일 교환에 도입하기에는 비용 부담이 크다. 

따라서 도청 위험을 허용할 수 있는 메시지 교환에는 종전대로 메일을 사용하고, 허용할 수 없는 메시지 교환에는 비즈니스 채팅이나 S/MIME 등을 사용하는 것이 현실화될 것이다. ‘적재적소’로 구분해서 사용하는 것이다.

일본 최대의 메일 보안 벤더인 TwoFive의 스에마사(末政) 사장은 “고전적인 메시지 교환 방식인 우편에서는 이 생각이 채용되었다. 지금도 널리 쓰이는 엽서는 적혀 있는 내용이 보호되지 않는다. 내용을 읽으려면 누구나 읽을 수 있다. 이용자는 그것을 이해한 후에 사용하고 있다”고 설명한다. 메일도 리스크를 이해한 후에 이용하는 것이 중요하다.

 -- 끝 --

Copyright © 2020 [Nikkei Network] / Nikkei Business Publications, Inc. All rights reserved.