간단히 말해서, MTA-STS는 메일 서버 간에 전송될 때 이메일을 가로채기(예: 중간자 공격, 즉 MitM)로부터 추가로 보호하는 방법입니다. 이는 이메일 프로토콜의 레거시 아키텍처 문제를 부분적으로 해결하며 상대적으로 최근의 표준 RFC 8461에 설명되어 있습니다. Mail.ru는 이 표준을 구현하는 RuNet의 첫 번째 주요 메일 서비스입니다. 그리고 컷 아래에 더 자세히 설명되어 있습니다.

MTA-STS는 어떤 문제를 해결합니까?

역사적으로 이메일 프로토콜(SMTP, POP3, IMAP)은 정보를 일반 텍스트로 전송했기 때문에 예를 들어 통신 채널에 액세스할 때 정보를 가로챌 수 있었습니다.

한 사용자가 다른 사용자에게 편지를 전달하는 메커니즘은 다음과 같습니다.

역사적으로 MitM 공격은 메일이 유통되는 모든 곳에서 가능했습니다.

RFC 8314에서는 MUA(메일 사용자 애플리케이션)와 메일 서버 간에 TLS를 사용해야 합니다. 서버와 사용하는 메일 애플리케이션이 RFC 8314를 준수한다면 사용자와 메일 서버 간의 중간자 공격 가능성이 (대부분) 제거된 것입니다.

일반적으로 허용되는 방식(RFC 8314로 표준화됨)을 따르면 사용자 근처의 공격을 제거할 수 있습니다.

Mail.ru 메일 서버는 표준이 채택되기 전에도 RFC 8314를 준수했습니다. 실제로 이는 이미 허용된 관행을 캡처할 뿐이며 추가로 구성할 필요가 없었습니다. 그러나 메일 서버에서 여전히 사용자가 안전하지 않은 프로토콜을 사용하도록 허용하는 경우 이 표준의 권장 사항을 구현해야 합니다. 귀하가 지원하더라도 최소한 일부 사용자는 암호화 없이 메일을 사용합니다.

메일 클라이언트는 항상 동일한 조직의 동일한 메일 서버에서 작동합니다. 그리고 모든 사용자가 안전한 방식으로 연결하도록 강제한 다음 보안되지 않은 사용자가 연결하는 것을 기술적으로 불가능하게 만들 수 있습니다(이것이 바로 RFC 8314에서 요구하는 것입니다). 이것은 때로는 어렵지만 가능합니다. 메일 서버 간의 트래픽은 여전히 ​​더 복잡합니다. 서버는 서로 다른 조직에 속하며 종종 "설정 후 잊어버리기" 모드로 사용되므로 연결을 끊지 않고 한 번에 보안 프로토콜로 전환하는 것이 불가능합니다. SMTP는 암호화를 지원하는 서버가 TLS로 전환할 수 있도록 하는 STARTTLS 확장을 오랫동안 제공해 왔습니다. 그러나 트래픽에 영향을 미칠 수 있는 공격자는 이 명령 지원에 대한 정보를 "삭제"하고 서버가 일반 텍스트 프로토콜을 사용하여 통신하도록 강제할 수 있습니다(소위 다운그레이드 공격). 같은 이유로 STARTTLS는 일반적으로 인증서의 유효성을 확인하지 않습니다(신뢰할 수 없는 인증서는 수동 공격으로부터 보호할 수 있으며 이는 일반 텍스트로 메시지를 보내는 것보다 나쁘지 않습니다). 따라서 STARTTLS는 수동적 도청으로부터만 보호합니다.

MTA-STS는 공격자가 트래픽에 적극적으로 영향을 미칠 수 있는 경우 메일 서버 간의 편지를 가로채는 문제를 부분적으로 제거합니다. 수신자의 도메인이 MTA-STS 정책을 게시하고 발신자 서버가 MTA-STS를 지원하는 경우 TLS 연결을 통해서만 이메일을 보내고, 정책에 정의된 서버에만 서버 인증서 확인을 통해서만 이메일을 보냅니다.

왜 부분적으로? MTA-STS는 양 당사자가 이 표준을 구현하기 위해 주의를 기울인 경우에만 작동하며, MTA-STS는 공격자가 공용 CA 중 하나에서 유효한 도메인 인증서를 얻을 수 있는 시나리오로부터 보호하지 않습니다.

MTA-STS 작동 방식

받는 사람

1. 메일 서버에서 유효한 인증서를 사용하여 STARTTLS 지원을 구성합니다. 
2. HTTPS를 통해 MTA-STS 정책을 게시합니다. 예를 들어 게시에는 특별한 mta-sts 도메인과 잘 알려진 특별한 경로가 사용됩니다. https://mta-sts.mail.ru/.well-known/mta-sts.txt. 정책에는 이 도메인에 대한 메일을 수신할 권한이 있는 메일 서버(mx) 목록이 포함되어 있습니다.
3. 정책 버전을 사용하여 DNS에 특수 TXT 레코드 _mta-sts를 게시합니다. 정책이 변경되면 이 항목을 업데이트해야 합니다. 이는 보낸 사람에게 정책을 다시 쿼리하라는 신호를 보냅니다. 예를 들어, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

보내는 사람

발신자는 _mta-sts DNS 레코드를 요청하고, 가능한 경우 HTTPS를 통해 정책 요청(인증서 확인)을 합니다. 결과 정책은 캐시됩니다(공격자가 정책에 대한 액세스를 차단하거나 DNS 레코드를 스푸핑하는 경우).

메일을 보낼 때 다음 사항을 확인합니다.

• 메일이 배달되는 서버는 정책에 있습니다.
• 서버는 TLS(STARTTLS)를 사용하여 메일을 수락하고 유효한 인증서를 가지고 있습니다.

MTA-STS의 장점

MTA-STS는 대부분의 조직에서 이미 구현된 기술(SMTP+STARTTLS, HTTPS, DNS)을 사용합니다. 수신자 측 구현에는 표준에 대한 특별한 소프트웨어 지원이 필요하지 않습니다.

MTA-STS의 단점

웹 및 메일 서버 인증서의 유효성, 이름 일치, 적시 갱신을 모니터링해야 합니다. 인증서에 문제가 있으면 메일이 배달되지 않을 수 있습니다.

발신자 측에서는 MTA-STS 정책을 지원하는 MTA가 필요합니다. 현재 MTA-STS는 MTA에서 기본적으로 지원되지 않습니다.

MTA-STS는 신뢰할 수 있는 루트 CA 목록을 사용합니다.

MTA-STS는 공격자가 유효한 인증서를 사용하는 공격으로부터 보호하지 않습니다. 대부분의 경우 서버 근처의 MitM은 인증서 발급 기능을 의미합니다. 이러한 공격은 인증서 투명성을 사용하여 탐지할 수 있습니다. 따라서 일반적으로 MTA-STS는 트래픽 가로채기 가능성을 완화하지만 완전히 제거하지는 않습니다.

마지막 두 가지 사항으로 인해 MTA-STS는 경쟁하는 SMTP용 DANE 표준(RFC 7672)보다 덜 안전하지만 기술적으로는 더 안정적입니다. MTA-STS의 경우 표준 구현으로 인한 기술적 문제로 인해 서신이 배달되지 않을 가능성이 낮습니다.

경쟁 표준 - DANE

DANE은 DNSSEC를 사용하여 인증서 정보를 게시하며 외부 인증 기관에 대한 신뢰를 요구하지 않으므로 훨씬 더 안전합니다. 그러나 DNSSEC를 사용하면 수년간의 사용 통계에 따르면 기술적인 실패로 이어지는 경우가 훨씬 더 많습니다(DNSSEC의 신뢰성과 기술 지원에는 일반적으로 긍정적인 추세가 있지만). 수신자 측 SMTP에서 DANE을 구현하려면 DNS 영역에 대한 DNSSEC가 있어야 하며, DNSSEC에 시스템적인 문제가 있는 DANE의 경우 NSEC/NSEC3에 대한 올바른 지원이 필수적입니다.

DNSSEC가 올바르게 구성되지 않은 경우 송신 측에서 DANE을 지원하면 수신 측에서 이에 대해 전혀 모르더라도 메일 전송에 실패할 수 있습니다. 따라서 DANE은 더 오래되고 더 안전한 표준이고 발신자 측의 일부 서버 소프트웨어에서 이미 지원되고 있음에도 불구하고 실제로 보급률은 미미하며 DNSSEC 구현의 필요성으로 인해 많은 조직에서 이를 구현할 준비가 되어 있지 않습니다. 이로 인해 표준이 존재했던 수년 동안 DANE 구현이 크게 느려졌습니다.

DANE과 MTA-STS는 서로 충돌하지 않으며 함께 사용할 수 있습니다.

Mail.ru Mail의 MTA-STS 지원은 무엇입니까?

Mail.ru는 꽤 오랫동안 모든 주요 도메인에 대한 MTA-STS 정책을 게시해 왔습니다. 우리는 현재 표준의 클라이언트 부분을 구현하고 있습니다. 작성 시점에서는 비차단 모드로 정책이 적용되고(정책에 의해 전달이 차단된 경우 정책을 적용하지 않고 '예비' 서버를 통해 편지가 전달됨) 일부에 대해 차단 모드가 강제 적용됩니다. 나가는 SMTP 트래픽 중 점차적으로 트래픽의 100%에 대해 정책 시행이 지원됩니다.

이 표준을 지지하는 또 다른 사람은 누구입니까?

지금까지 MTA-STS 정책은 활성 도메인의 약 0.05%를 게시했지만 그럼에도 불구하고 이미 대량의 메일 트래픽을 보호하고 있습니다. 이 표준은 Google, Comcast 및 일부 Verizon(AOL, Yahoo) 등 주요 업체에서 지원됩니다. 다른 많은 우편 서비스에서는 가까운 시일 내에 표준에 대한 지원이 구현될 것이라고 발표했습니다.

이것이 나에게 어떤 영향을 미치나요?

도메인이 MTA-STS 정책을 게시하지 않는 한 그렇지 않습니다. 정책을 게시하면 메일 서버 사용자의 이메일이 가로채기로부터 더 잘 보호됩니다.

MTA-STS를 어떻게 구현하나요?

수신자 측의 MTA-STS 지원

HTTPS를 통해 정책을 게시하고 DNS에 기록하고, MTA의 STARTTLS에 대해 신뢰할 수 있는 CA 중 하나에서 유효한 인증서를 구성하는 것(암호화 가능)으로 충분합니다(STARTTLS는 모든 최신 MTA에서 지원됨). MTA가 필요합니다.

단계별로 보면 다음과 같습니다.

1. 사용 중인 MTA(postfix, exim, sendmail, Microsoft Exchange 등)에서 STARTTLS를 구성하십시오.
2. 유효한 인증서(신뢰할 수 있는 CA에서 발급하고 만료되지 않았으며 인증서 제목이 도메인에 메일을 전달하는 MX 레코드와 일치함)를 사용하고 있는지 확인하세요.
3. TLS 보고서 전송을 지원하는 서비스를 통해 정책 적용 보고서가 전달될 TLS-RPT 레코드를 구성합니다. 예제 항목(example.com 도메인의 경우):

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»

   이 항목은 메일 발신자에게 SMTP의 TLS 사용에 대한 통계 보고서를 보내도록 지시합니다. [email protected].

   며칠 동안 보고서를 모니터링하여 오류가 없는지 확인하세요.

4. HTTPS를 통해 MTA-STS 정책을 게시합니다. 정책은 위치별로 CRLF 줄 종결자가 포함된 텍스트 파일로 게시됩니다.

   https://mta-sts.example.com/.well-known/mta-sts.txt
   

   정책 예시:

   version: STSv1
   mode: enforce
   mx: mxs.mail.ru
   mx: emx.mail.ru
   mx: mx2.corp.mail.ru
   max_age: 86400
   

   버전 필드에는 정책 버전(현재 STSv1), 모드는 정책 적용 모드, 테스트 - 테스트 모드(정책이 적용되지 않음), 시행 - "전투" 모드를 설정합니다. 먼저 모드: 테스트를 사용하여 정책을 게시합니다. 테스트 모드에서 정책에 문제가 없으면 잠시 후 모드: 적용으로 전환할 수 있습니다.

   mx에서는 도메인의 메일을 수락할 수 있는 모든 메일 서버 목록이 지정됩니다. 각 서버에는 mx에 지정된 이름과 일치하는 인증서가 구성되어 있어야 합니다. Max_age는 정책의 캐싱 시간을 지정합니다(공격자가 캐싱 시간 동안 정책 전달을 차단하거나 DNS 레코드를 손상시키더라도 기억된 정책이 적용되면 mta-sts DNS를 변경하여 정책을 다시 요청해야 한다는 신호를 보낼 수 있음). 기록).

5. DNS에 TXT 레코드 게시: 

   _mta-sts.example.com. TXT “v=STS1; id=someid;”
   

   id 필드에는 임의의 식별자(예: 타임스탬프)를 사용할 수 있습니다. 정책이 변경되면 정책도 변경되어야 하며, 이를 통해 발신자는 캐시된 정책을 다시 요청해야 함을 이해할 수 있습니다(식별자가 정책과 다른 경우). 캐시된 것).

발신자 측의 MTA-STS 지원

지금까지 그녀의 상황은 좋지 않았습니다. 왜냐면... 신선한 기준.

• Exim - 내장된 지원이 없으며 타사 스크립트가 있습니다. https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix - 내장된 지원은 없습니다. Habré에 자세히 설명된 타사 스크립트가 있습니다. https://habr.com/en/post/424961/

"필수 TLS"에 대한 후기

최근 규제 당국은 이메일 보안에 주의를 기울이고 있습니다. 이는 좋은 일입니다. 예를 들어, DMARC는 미국의 모든 정부 기관에 의무적으로 적용되며 금융 부문에서도 점점 더 요구되고 있으며 규제 지역에서는 표준 보급률이 90%에 달합니다. 이제 일부 규제 기관에서는 개별 도메인에 "필수 TLS" 구현을 요구하지만 "필수 TLS"를 보장하는 메커니즘은 정의되어 있지 않으며 실제로 이 설정은 이미 실행되고 있는 실제 공격에 대해 최소한의 보호도 하지 못하는 방식으로 구현되는 경우가 많습니다. DANE 또는 MTA-STS와 같은 메커니즘에서 제공됩니다.

규제 기관에서 별도의 도메인을 사용하여 "필수 TLS" 구현을 요구하는 경우 MTA-STS 또는 해당 부분 아날로그를 가장 적합한 메커니즘으로 고려하는 것이 좋습니다. 이렇게 하면 각 도메인에 대해 별도로 보안 설정을 지정할 필요가 없습니다. MTA-STS의 클라이언트 부분을 구현하는 데 어려움이 있는 경우(프로토콜이 광범위한 지원을 받을 때까지) 다음 접근 방식을 권장할 수 있습니다.

1. MTA-STS 정책 및/또는 DANE 레코드를 게시합니다(DANE은 도메인에 대해 DNSSEC가 이미 활성화되어 있고 어떤 경우에도 MTA-STS가 활성화된 경우에만 의미가 있음). 이렇게 하면 사용자가 향하는 트래픽을 보호하고 다른 메일 서비스에 문의할 필요가 없습니다. 메일 서비스가 이미 MTA-STS 및/또는 DANE을 지원하는 경우 도메인에 필수 TLS를 구성합니다.
2. 대규모 이메일 서비스의 경우 각 도메인에 대한 별도의 전송 설정을 통해 MTA-STS의 "아날로그"를 구현합니다. 이렇게 하면 메일 릴레이에 사용되는 MX가 수정되고 이에 대한 TLS 인증서의 필수 확인이 필요합니다. 도메인이 이미 MTA-STS 정책을 게시한 경우 이 작업은 쉽게 수행될 수 있습니다. 릴레이를 수정하고 인증서를 확인하지 않고 도메인에 대해 필수 TLS를 활성화하는 것은 보안 관점에서 효과적이지 않으며 기존 STARTTLS 메커니즘에 아무 것도 추가하지 않습니다.

출처 : habr.com