디지털 커뮤니케이션 기술로서 이메일은 계속해서 지배적이며 사용량이 증가하고 있습니다. 이전 게시물 에서 많은 장점을 강조했지만 대부분의 사용자가 전혀 인식하지 못하는 몇 가지 약점도 언급했습니다.

이 게시물에서 우리는 이러한 약점을 보다 자세히 살펴보고 특히 이메일이 서버 간에 전송되는 방식에 대해 살펴보겠습니다. 또한 기존 이메일 프로토콜(예: DANE)에 대해 확립된 확장을 채택함으로써 이러한 약점을 어떻게 해결할 수 있는지 강조할 것입니다.

항상 그렇듯이 이 기사는 해당 주제에 대한 개인적인 연구와 실습을 기반으로 하지만 지식 공유는 공동 작업이므로 의견이나 피드백을 제공하십시오.

소개

이해를 돕기 위해 메일 서버 간의 연결이 설정되는 방법에 대한 세 가지 높은 수준의 단계를 강조하겠습니다.

수신자 메일 서버 검색 , 주어진 수신자 도메인에 대한 메일을 수락할 메일 서버를 검색하는 프로세스입니다 .

수신자 메일 서버에 연결 , 올바른 메일 서버 식별, 연결 프로세스 및 적절한 암호화(일명 TLS)로 연결 보안.

수신자 메일 서버가 실제로 올바른 것인지 확인 하여 수신자 도메인의 합법적인 서버에 대한 보안 연결을 설정했는지 확인할 수 있습니다.

수신자 메일 서버 검색

이는 수신자 도메인에 대한 메일을 수신하도록 의도된 메일 서버의 하나 이상의 IP 주소를 가리키는 MX(메일 교환) 레코드의 DNS 조회를 통해 가장 일반적으로 수행 됩니다. 그러나 MTA-STS, SRV 레코드 또는 A 레코드와 같은 다른 메커니즘이 있습니다. 아래에서 MTA-STS의 일부 요소를 더 다루겠지만 SRV/A 레코드 접근 방식은 다루지 않습니다(동일한 약점을 공유하긴 하지만).

메일 서버의 검색은 DNS 에 의존하며 대부분의 DNS 쿼리는 여전히 UDP 패킷에 의존하므로 연결이 없고 암호화되지 않으므로 스푸핑된 응답을 가로채고 삽입하기가 상대적으로 쉽습니다.

TCP, TLS, 심지어 HTTPS 를 통한 DNS를 사용하는 DNS 구현이 있기는 하지만 일반적이지 않지만 클라이언트와 서버 간의 가로채기 및 주입 가능성을 줄입니다.

그러나 TCP/TLS의 배포는 연결을 개선하거나 보안하는 데 중점을 두지만 DNS 조회에 대한 응답인 데이터가 진짜이고 변조되지 않았음을 보장하는 메커니즘을 제공하지 않습니다.

이것이 바로 DNSSEC 가 등장하는 곳이며, DNSSEC 지원 도메인에 대한 모든 DNS 응답이 정품이고 신뢰할 수 있는 것으로 암호학적으로 검증될 수 있도록 보장하는 트러스트 앵커 디지털 서명 접근 방식을 제공합니다.

데인은 어때?

• DANE는 모든 DNS 조회에 대해 DNSSEC를 요구하므로 이 위험을 성공적으로 완화합니다.

• MTA-STS는 웹 서버에서 호스팅되는 MTA-STS 정책 파일 내에 메일 서버를 나열하여 도메인에 대한 권한이 있는 메일 서버를 게시합니다. 웹 서버 자체에 대한 연결은 HTTPS(인증서 유효성 검사 포함)일 수 있지만 해당 웹 서버의 DNS 조회가 안전할 필요는 없습니다.
• MTA-STS는 DNSSEC 사용을 의무화하지 않습니다. 사실 제가 이해한 것은 MTA-STS의 '설계 기능' 중 하나는 DNSSEC에 의존하지 않는다는 것이었습니다.

• 수신자 도메인 메일 서버의 검색은 DNSSEC가 없으면 수신된 응답을 보장할 수 있는 보안이 부족한 DNS에 의존합니다.
• DANE은 DNSSEC 사용을 의무화하므로 SMTP의 확장으로서 이러한 위험에 대한 보호를 제공하는 가장 효과적인 메커니즘입니다.
• MTA-STS는 DNSSEC 사용을 의무화하지 않으며 HTTPS 보안 서버에서 정책을 호스팅함에도 불구하고 여전히 기존 DNS 조회에 의존합니다.
• 그러나 MTA-STS는 이러한 위험의 대부분을 완화하는 DNSSEC와 함께 배포될 수 있습니다. MTA-STS를 배포하는 과정에 있다면 이것이 제 권장 사항이 될 것입니다.

세상은 눈 깜짝할 사이에 HTTPS로 이동했습니다. 오늘날 HTTPS를 지원하지 않는 웹사이트를 찾는 것은 매우 드문 일입니다. 그러나 이메일은 보안에서 동일한 단계 변화를 보지 못했고 여전히 "기회적 TLS"라고 부르는 것에 의존합니다. Opportunistic TLS에서 서버는 먼저 안전하지 않은 연결을 만든 다음 협상을 시도하고 TLS에 대한 연결을 업그레이드하지만 어떤 이유로든 동의할 수 없는 경우 TLS 없이 행복하게 계속합니다.

여기서 진짜 문제는 "Opportunistic TLS"가 처음에 안전하지 않은 연결을 열고 이를 TLS로 업그레이드한다는 것입니다(STARTTLS 방법에 의해 시작됨). 따라서 이러한 연결을 가로채고 원격 서버에서 STARTTLS 지원을 마스킹하여 TLS로의 업그레이드를 금지하는 것은 상대적으로 쉽습니다. 기회주의적 TLS 메일 서버는 관심이나 고려 없이 이메일 교환을 계속합니다. 더 나쁜 것은 보낸 사람이나 받는 사람 모두 이러한 일이 발생했음을 원격으로 인식하지 못할 것입니다.

TLS 연결의 양 당사자는 PKI 인증서를 활용합니다. 이 인증서는 당사자가 진정으로 자신이 누구인지에 대한 추가적인 신뢰 수준을 제공하고 트러스트 앵커 를 통해 독립적으로 확인할 수 있습니다. 그러나 LetsEncrypt와 같은 공급자로부터 인증서를 얻는 것이 얼마나 쉬운지를 고려할 때 이는 신뢰성이 떨어집니다.

실제로 대부분의 이메일 서버는 일종의 TLS를 지원하므로 이메일이 인터넷을 통과하여 목적지로 이동할 때 암호화되었을 가능성이 매우 높습니다. 그러나 TLS 지원을 마스킹하고 암호화되지 않은 연결을 허용하는 MITM 공격 의 위험은 다루지 않습니다 .

MTA-STS는 어떻습니까?

• MTA-STS는 이메일 교환을 위해 TLS 연결을 설정해야 함을 암시적으로 요구함으로써(그리고 '테스트' 모드에 있지 않다고 가정하여) 이 위험을 해결합니다.

• DANE는 TLS 연결에 대한 암시적 요구 사항을 적용하므로 이 위험을 완화합니다.

• 편의적 TLS는 TLS로의 업그레이드 가능성을 설정하기 위해 암호화되지 않은 연결에 의존하므로 MITM 공격에 취약합니다.
• DANE 및 MTA-STS는 이메일을 교환하기 전에 암묵적으로 TLS 연결이 필요하므로 최소한 기본 TLS 연결이 설정되도록 하는 데 효과적입니다.
• TLS만으로는 연결이 충분히 보안/암호화되었음을 시사하기에 충분하지 않습니다. TLS 내에서 구현된 많은 프로토콜 및 암호화 제품군은 안전하지 않은 것으로 간주됩니다(무차별 대입 가능). 이것은 이후 기사에서 다룰 전체 주제입니다.

이는 틀림없이 메일 서버 간에 보안 연결을 설정하는 과정의 한 단계입니다. 그러나 제 생각에는 자체 섹션을 가질 가치가 있는 매우 중요한 요소입니다.

이전 단계에 대한 종속성을 인식하면 연결하려는 서버가 실제로 수신자 도메인에 대해 권한이 있는 서버인지 추가로 검증할 수 있어야 합니다. 이전 단계에서는 인증서 확인을 포함하거나 포함하지 않을 수 있는 TLS 연결 설정에 대해 설명했습니다. 그러나 일반적으로 인증서 확인이 일반적으로 수행하는 모든 작업은 지정된 호스트 이름이 원격 서버의 인증서에 설명된 호스트 이름과 일치하는지 확인하고 선택적으로 트러스트 앵커에 다시 연결할 수 있는지 확인하는 것입니다.

DANE는 주어진 메일 서버 인증서에 대한 지문(및 유효성 검사 방법)을 보유하는 DNSSEC 보안 TLSA 레코드를 게시하여 한 단계 더 나아갑니다. 이는 연결하는 서버가 DNS 관리자가 인식하는 특정 인증서를 제시하고 있음을 절대적으로 보장하는 안정적이고 궁극적인 유효성 검사를 제공합니다.

데인은 어때?

• DNSSEC 보안 TLSA 레코드에 대한 서버 인증서의 유효성 검사는 DANE 고유의 기능이며 연결을 보장하기 위한 최종 승인 봉인을 제공합니다.

• MTA-STS는 여기까지 가지 않습니다. 목적은 TLS 연결이 필수임을 확인하는 데 있으며 메일 서버의 권한을 확인하는 데까지 확장되지 않습니다.

제 생각에는 대부분의 메일 제공업체에서 이러한 약점이 완화되지 않은 상태로 유지되어야 하는 합리적인 이유가 없습니다. 이 기술은 이를 해결하기 위해 존재하며 요즘에는 비교적 쉽게 배포할 수 있습니다. 내 가정은 소비자의 인식 부족으로 인해 메일 제공업체가 이러한 기술을 구현하려는 동기가 상당 부분 제거된다는 것입니다.

MTA-STS는 편의적 TLS 문제에 대한 몇 가지 주요 개선 사항을 제공하지만 모든 약점을 해결하기에는 충분하지 않습니다. MTA-STS에 DNSSEC를 추가하면 일부 위험이 줄어들고 제 권장 사항이 될 것입니다(DANE이 옵션이 아닌 경우).

그러나 DANE은 이 문서에서 논의된 약점에 대한 포괄적인 솔루션을 제공합니다. MTA-STS와 DANE을 모두 고려하고 있지만 하나만 선택하고 싶다면 DANE을 추천합니다.

전 세계적으로 약 3억 6,500만 개의 도메인 이름이 등록되어 있으며 370만 도메인만이 DANE를 배포했습니다 (약 1%).

가장 큰 메일 공급자를 살펴보면 Gmail이 MTA-STS를 배포했지만 아직 DANE 또는 DNSSEC를 배포하지 않은 것을 알 수 있습니다.

마찬가지로 Microsoft는 올해 Exchange Online에 MTA-STS를 배포 했으며 향후 DANE를 제공할 계획 이라고 발표 했지만 아웃바운드와 인바운드를 모두 지원하려면 몇 년 더 걸릴 것으로 보입니다.