SMTP TLS 보고란 무엇인가요?

읽기 시간: 8 분

조직에서 이메일을 주요 커뮤니케이션 수단으로 점점 더 많이 사용함에 따라 잠재적인 위협으로부터 이러한 채널을 강화하는 것의 중요성은 아무리 강조해도 지나치지 않습니다. TLS(전송 계층 보안)는 네트워크를 통해 전송되는 데이터의 기밀성과 무결성을 보장하는 초석 역할을 합니다. 

여러 프로토콜은 사이버 공격자가 이메일 통신을 가로채지 못하도록 SMTP 메시지 채널을 암호화하는 데 도움이 됩니다. 여기에는 STARTTLS, DANE 및 MTA-STS가 포함됩니다. 그러나 이러한 프로토콜을 사용하는 동안 암호화 시도가 실패하면 이메일이 전달되지 않을 수 있습니다. TLS-RPT( RFC 8460)는 이러한 배달 실패에 대해 보고하는 피드백 메커니즘을 제공합니다.

TLS-RPT를 다음과 함께 사용할 것을 적극 권장합니다. MTA-STS 프로토콜과 함께 사용할 것을 적극 권장합니다. 이러한 프로토콜이 어떻게 함께 작동하여 이메일 보안을 강화하는지 알아보세요.

TLS-RPT란 무엇인가요?

TLS-RPT는 전송 계층 보안 보고의 약자입니다. 이메일이 TLS로 암호화되지 않았을 때 발생하는 이메일 전송 문제를 보고하기 위한 표준입니다. 이메일 인증에서 이 표준의 중요성은 이메일에 TLS 암호화를 사용하도록 설정하는 이유와도 밀접한 관련이 있습니다. 

TLS 암호화는 사용자에게 전송되는 모든 이메일이 안전하게 전달되도록 보장합니다. 연결이 안전하지 않은 경우 이메일이 전달되지 않는 경우가 많습니다. 도메인 소유자는 TLS-RPT를 통해 이메일 전송 및 연결 실패를 모니터링할 수 있습니다. 보고서에는 다음에 대한 정보가 포함될 수 있습니다: 

• MTA-STS 정책 처리 문제 
• 배송 실패 이유 및 유형
• 이메일 송수신 메일 전송 에이전트의 IP 주소
• 성공 및 실패한 TLS 연결 세션의 총 개수 

이를 통해 이메일 채널에 대한 가시성을 확보하고 전달률 문제에 더 빠르게 대응할 수 있습니다. 

TLS 보고는 어떻게 작동하나요?

SMTP 이메일 통신에서 TLS 암호화는 "기회주의적" 암호화입니다. 즉, 암호화된 채널을 협상할 수 없는 경우 이메일은 여전히 암호화되지 않은(일반 텍스트) 형식으로 전송됩니다. 사실 거의 40년 전만 해도 SMTP 이메일 프로토콜은 TLS 암호화를 지원하지 않았습니다. 이 기능은 나중에 STARTTLS 명령의 형태로 추가되어야 했습니다. 

STARTTLS 명령은 양쪽이 모두 TLS 암호화를 지원하는 경우에만 SMTP 통신에서 실행됩니다. 그렇지 않으면 이메일은 여전히 일반 텍스트로 전송됩니다. 

SMTP에서 기회주의적 암호화를 없애기 위해 MTA-STS가 도입되었습니다(RFC 8461). MTA-STS 프로토콜은 이메일이 전달되기 전에 암호화되도록 합니다. 이메일 서버 또는 MTA(메일 전송 에이전트)는 수신 서버와 협상하여 STARTTLS 명령을 지원하는지 확인합니다. 지원하는 경우 이메일이 TLS로 암호화되어 배달됩니다. 그렇지 않으면 배달에 실패합니다.

TLS 암호화 실패에는 여러 가지 이유가 있을 수 있습니다. 어느 한쪽에서 암호화를 지원하지 않는 것 외에도 SMTP 다운그레이드 공격과 같은 더 불길한 이유로 인해 TLS 연결이 실패할 수 있습니다. MTA-STS를 사용하면 공격자는 연결 실패 시 일반 텍스트로 메시지를 전달할 수 없게 됩니다. 

하지만 도메인 소유자는 배달 실패에 대해 알고 싶어할 것입니다. TLS 보고(TLS-RPT)는 이를 알려주는 프로토콜입니다. 배달에 실패하면 TLS-RPT 레코드에 정의된 이메일 주소로 JSON 파일 형식의 TLS 보고서를 받게 됩니다. 

SMTP TLS 보고가 필요한 이유는 무엇인가요?

도메인 소유자는 이메일에 대한 정보를 계속 확인해야 합니다.

MTA-STS 사용 도메인에서 보낸 이메일에 대한 TLS 암호화 실패로 인한 배달 문제. TLS 보고는 이 정보를 제공함으로써 이를 가능하게 합니다. TLS-RPT 

• 정책 유형을 강조하는 피드백 보고서를 받으려면 다음과 같이 하세요. 
• TLS 암호화 실패의 원인을 파악하려면 다음과 같이 하세요.
• 이메일 채널에 대한 가시성을 확보하려면
• 배달 문제를 해결하려면

TLS-RPT 설정 단계

TLS-RPT용 TXT 레코드를 만들고 DNS에 게시하여 도메인에 대한 TLS 보고를 사용 설정할 수 있습니다. 이 레코드는 하위 도메인인 smtp.tls.yourdomain.com

1단계: TLS-RPT 레코드 생성 도구 선택

당신은 할 수 있습니다 가입 에 무료로 가입하고 TLS-RPT 레코드 생성기를 사용하여 레코드를 생성할 수 있습니다.

2단계: 보고 이메일 주소 입력

SMTP TLS 보고서를 수신할 이메일 주소를 입력합니다.

3단계: DNS에 TLS 레코드 게시하기

도메인 등록기관에 문의하여 TLS-RPT용 TXT 레코드를 새로 만들 수 있습니다. 자체 DNS를 관리하는 경우 해당 레코드를 포함하도록 DNS 설정을 편집하세요.

TLS-RPT 레코드 예시

구문: v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com;

제공된 TLS 보고 레코드의 두 가지 구성 요소를 분석해 보겠습니다:

1. v=TLSRPTv1: 이 태그는 사용 중인 TLS-RPT 프로토콜의 버전을 지정합니다. 이 경우 "TLSRPTv1" 은 프로토콜의 첫 번째 버전을 나타냅니다.
2. rua=mailto:tlsrpt@yourdomain.com: rua는 '집계 데이터에 대한 보고 URI(들)의 약자입니다. 이 태그는 수신자의 메일 서버가 집계된 TLS 보고서를 보낼 위치를 지정합니다.

보고서를 받을 대상을 두 개 이상 구성할 수 있습니다. 여러 대상의 경우 각 항목을 쉼표(,)로 구분하세요. "maito:"를 사용하여 이 단계의 이메일 주소를 지정하거나, rua= 필드에 "https:"를 사용하여 엔드포인트 URL로 POST를 통해 보고서를 제출하도록 MTA에 지시할 수 있습니다. "https:"를 사용하는 경우 필드가 유효한 인증서가 있는 HTTPS 사용 웹 서버의 URL을 정의하는지 확인하세요. "mailto:"와 "https:"는 쉼표로 구분하여 하나의 레코드에 모두 사용할 수도 있습니다. 

예: v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://tlsreport.example.com;

참고: 참고: 실제로는 "yourdomain.com" 을 이러한 보고서를 수신하려는 실제 도메인 이름으로 대체합니다.

TLS 보고 형식 

TLS 보고서는 JSON 형식으로 전송됩니다. 다음은 JSON TLS 보고서의 모습에 대한 예시입니다:

{

  "조직 이름": "조직 주식회사",

  “date-range”: {

    "시작-시간": “2020-10-22T00:00:00Z”,

    "종료 시간": “2020-10-22T23:59:59Z”

  },

  "contact-info": "smtp-tls-reporting@organization.com",

  "report-id": “2020-10-22T00:00:00Z_domain.com”,

  "정책": [

    {

      “policy”: {

        "정책 유형": "sts",

        "정책 문자열": [

          "version: STSv1",

          "모드: 테스트",

          "mx: mx.domain.com",

          "mx: mx2.domain.com",

          "mx: mx3.domain.com",

          "max_age: 604800"

        ],

        "정책-도메인": "domain.com"

      },

      “summary”: {

        "총-성공-세션-수": 15,

        "총-실패-세션-수": 0

      }

다음은 이 JSON TLS 보고서의 주요 필드에 대한 분석입니다: 

필드	설명
조직	TLS-RPT 레코드를 소유한 도메인 조직입니다.
이메일	집계된 보고서가 전송되는 이메일 주소입니다.
시작_날짜	보고 기간의 시작일입니다.
end_date	보고 기간의 종료일입니다.
정책	보고 기간 동안 적용된 정책을 설명하는 정책 개체 배열입니다.
정책	적용된 정책에 대한 정보가 포함되어 있습니다.
정책 유형	정책 유형을 지정합니다.
정책 문자열	정책과 연결된 정책 문자열을 지정합니다.
모드	MTA-STS 정책 모드(적용/테스트)를 지정합니다.
요약	시도한 세션에 대한 요약 정보를 포함합니다.
총_성공_세션_수	성공적으로 설정된 TLS 세션의 총 개수입니다.
총_실패_세션_수	TLS 세션 실패의 총 횟수입니다.
실패 _ 세부 정보	특정 장애에 대한 세부 정보를 제공하는 개체 배열입니다.
이유	실패 이유를 나타내는 문자열(예: "인증서_만료됨")입니다.
카운트	특정 이유로 실패한 세션의 수입니다.

TLS 암호화 실패 이유 및 유형

인증서 발급

실패 유형	이유	가능한 문제 해결 제안 사항
인증서_만료	원격 서버에서 제공한 인증서의 만료 날짜가 지났습니다. 따라서 암호화를 위해 신뢰할 수 없습니다.	인증서를 갱신합니다.
인증서_not_valid_yet	원격 서버에서 제공한 인증서가 아직 유효하지 않습니다. 이는 서버 시간이 잘못되었거나 인증서를 너무 일찍 사용했기 때문일 수 있습니다.	인증서 공급업체에 문의하세요.
인증서_취소	원격 서버에서 제공한 인증서가 보안 문제로 인해 인증 기관에서 해지되었습니다.	인증서 공급업체에 문의하세요.
no_valid_signature	원격 서버에서 제공하는 인증서 체인은 발신자의 메일 서버 또는 클라이언트에서 신뢰할 수 없으므로 잠재적인 보안 위험을 나타냅니다.	인증서 공급업체에 문의하세요.
지원되지 않는 인증서	원격 서버에서 제공하는 인증서는 발신자의 메일 서버에서 지원하지 않는 암호화 알고리즘 또는 키 길이를 사용하므로 보안 연결이 되지 않습니다.	인증서 공급업체에 문의하세요.

호스트 이름 및 ID 불일치

실패 유형	이유	가능한 문제 해결 제안 사항
호스트 이름_불일치	서버의 인증서에 지정된 호스트 이름이 발신자의 메일 서버가 연결하려는 서버의 호스트 이름과 일치하지 않습니다. 중간자 공격 또는 구성 문제가 있을 수 있음을 나타냅니다.	MTA-STS 정책 파일에서 MX 레코드를 확인하여 도메인의 MX 레코드와 일치하는지 확인합니다.

핸드셰이크 및 프로토콜 문제

실패 유형	이유	가능한 문제 해결 제안 사항
핸드셰이크_실패	발신자의 메일 서버와 수신자의 메일 서버 간의 초기 TLS 핸드셰이크 프로세스 중에 문제가 발생하여 보안 채널이 설정되지 않았습니다.	SMTP STARTTLS 연결이 설정되었는지 다시 확인하세요. STARTTLS 지원 부족 또는 TLS 다운그레이드 공격 등 암호화 실패의 원인에는 여러 가지가 있을 수 있습니다.

MTA-STS 정책 문제

실패 유형	이유	가능한 문제 해결 제안 사항
MTA_STS_정책_못_찾음	이 오류는 발신자의 메일 서버가 수신자 도메인에 대한 MTA-STS 정책을 찾을 수 없을 때 발생합니다.	MTA-STS 정책 파일을 검토합니다. MTA-STS 레코드가 올바르게 게시되었는지 확인합니다.
mta_sts_정책_무효	이 실패는 수신자 도메인의 DNS에 있는 MTA-STS 정책이 유효하지 않거나 오류가 있거나 MTA-STS 사양을 준수하지 않을 때 발생합니다.	MTA-STS 정책 파일을 검토합니다. 적절한 MTA-STS 정책 모드를 지정합니다. 없음, 적용 또는 테스트 중 하나를 선택할 수 있습니다. 이렇게 하면 보내는 서버에 MTA-STS 정책 유효성 검사에 실패한 이메일을 처리하는 방법을 지시합니다.  여기에서 정책 모드에 대해 자세히 알아보세요.
mta_sts_정책_페치_오류	이 오류는 발신자의 메일 서버가 수신자 도메인의 DNS 레코드에서 MTA-STS 정책을 검색하는 동안 오류가 발생할 때 발생합니다.	DNS에서 MTA-STS 레코드의 유효성을 검사하여 레코드 구문이 올바른지 확인합니다.
MTA_STS_연결_실패	이 실패는 발신자의 메일 서버가 MTA-STS를 사용하여 보안 연결을 설정하려고 시도하지만 신뢰할 수 없는 인증서, 지원되지 않는 암호 모음 또는 기타 TLS 문제와 같은 이유로 인해 실패할 때 발생합니다.	인증서 유효기간을 확인하고 인증서가 최신 TLS 표준으로 최신 상태인지 확인하세요.
mta_sts_invalid_hostname	이 오류는 MTA-STS 정책에 지정된 수신자 메일 서버의 호스트 이름이 서버의 실제 호스트 이름과 일치하지 않을 때 발생합니다.	MTA-STS 정책 파일에서 MX 레코드를 확인하여 도메인의 MX 레코드와 일치하는지 확인합니다.

PowerDMARC로 간소화된 SMTP TLS 보고

PowerDMARC의 SMTP TLS 보고 환경은 호스팅 서비스를 통해 보안을 개선하는 동시에 생활을 더욱 편리하게 만들어줍니다.

번역된 TLS 보고서

복잡한 TLS-RPT JSON 보고서가 몇 초 만에 훑어보거나 자세히 읽을 수 있는 간소화된 정보로 변환됩니다. 

문제 자동 감지

PowerDMARC 플랫폼은 사용자가 직면한 문제를 정확히 파악하고 강조 표시하여 시간 낭비 없이 문제를 해결할 수 있도록 도와줍니다. 

PowerDMARC 플랫폼은 사용하기 쉽고 이해하기 쉬운 레이아웃을 갖추고 있으며, 호스트형 DMARC 제어, SPF 플래트닝, 레코드의 세부 사항을 검사하기 위해 SPF 포함을 쉽게 확장할 수 있고, 심지어 MTA-STS 및 TLS-RPT를 완벽하게 지원하는 완전한 기능을 갖추고 있습니다!

딜런 B(비즈니스 소유자) 

전송 계층 보안에 관해 자주 묻는 질문

1. TLS는 무엇을 의미하나요?

TLS는 전송 계층 보안의 약자입니다. 

2. TLS 인증서는 누가 발급하나요? 

CA(인증 기관)는 TLS 인증서를 발급할 수 있습니다. 인증서를 발급하는 절차에는 인증서 소유자의 신원 확인이 포함됩니다. 본인 확인에 성공하면 인증서가 발급됩니다. 

3. TLS 인증서가 필요한 이유는 무엇인가요?

TLS 인증서는 인터넷을 통한 통신을 보호하는 데 중추적인 역할을 합니다. 통신하는 웹 서버 간에 교환되는 민감한 정보를 암호화하는 데 도움이 됩니다. 가장 일반적인 용도로는 이메일 통신 보안과 HTTPS가 있습니다. 

4. 현재 TLS 표준은 무엇인가요?

TLS 1.3은 전송 계층 보안의 최신 버전입니다. TLS-RPT는 모든 버전의 TLS를 사용하여 구현할 수 있습니다. 여기에는 프로토콜의 이전 버전이나 향후 버전이 포함될 수 있습니다. 버전은 일반적으로 통신하는 서버의 기능과 같은 기준에 따라 결정됩니다. 

추가 리소스

1. TLS-RPT 레코드 생성기 
2. TLS-RPT 레코드 검사기
3. MTA-STS 
4. DMARC