네트워크 연결 및 초기 SMTP 명령이 이미 작동한 후에 SMTP TLS 오류가 발생할 수 있습니다. 발신자는 프로토콜 버전 협상에 실패하거나, 인증서를 거부하거나, 핸드셰이크 중에 중단을 받을 수 있습니다. 이를 보낸 사람의 즉각적인 증거가 아닌 전송 계층 관찰로 처리합니다. SPF 또는 DKIM 기록이 잘못됐어요.
운송 모드 식별
SMTP 에서 STARTTLS, 클라이언트는 먼저 SMTP 설정하고 기능 광고를 수신하고 STARTTLS 요청한 다음 서버의 준비 응답 후 TLS 협상을 시작합니다. 암시적 TLS 연결 시 즉시 TLS 시작하며 일반적으로 지원되는 제출 서비스에 사용됩니다. 이러한 기대치를 혼합하면 유용한 메일 교환이 이루어지기 전에 연결이 실패할 수 있습니다. RFC 3207 섹션 4 및 5.
대상, 포트, 모드, 전송 소프트웨어, 원격 SMTP 인사말 및 광고 기능을 기록합니다. STARTTLS 제공되기 전, STARTTLS 명령 후, 인증서 처리 중 또는 핸드셰이크 후에 실패가 발생했는지 여부를 유지합니다. 개인 키, 비밀번호 또는 세션 비밀을 진단 패킷에 복사하지 마십시오. 인증서 메타데이터 및 수정된 프로토콜 오류는 일반적으로 모호한 "보안 연결 실패"보다 더 유용합니다.
실제 정책에 따라 인증서를 평가합니다.
만료된 인증서, 지원되지 않는 프로토콜, 불완전한 체인 또는 신원 불일치는 전송 정책에 따라 다르게 적용될 수 있습니다. 일반적인 기회주의적 SMTP TLS 다음에 의해 관리되는 연결과 동일한 보증 모델이 아닙니다. MTA-STS 또는 인증됨 DANE. 보낸 사람이 배달을 연기한 이유를 해석하기 전에 시행 중인 정책의 이름을 지정하세요. 모든 SMTP 구현이 모든 인증서를 동일하게 검증한다고 가정하지 마십시오.
RFC 8461 MTA-STS 정책 검색, 검증 및 시행 동작을 지정합니다. RFC 7672 DNSSEC 인증을 사용하여 DANE SMTP 전송 보안을 정의합니다. TLSA 정보. 이러한 메커니즘에는 고유한 요구 사항과 오류 처리가 있습니다. 이들의 존재는 단순히 로그에 TLS 오류가 나타난다는 이유만으로 추론되는 것이 아니라 실제 발신자 구성 및 관련 검색 증거를 통해 확인되어야 합니다.
가상의 신원 오류를 해결하세요.
승인된 제출 클라이언트가 submit.example 에서 암시적 TLS 에 대해 구성되어 있지만 해당 인증서 오류에 old-submit.example 의 예상 ID가 표시된다고 가정해 보겠습니다. 먼저 서비스의 현재 문서화된 엔드포인트와 클라이언트가 엔드포인트에 도달하고 있는지 확인하세요. 단지 나타나는 인증서가 통과되도록 하기 위해 예상 이름을 변경하지 마십시오.
서비스 소유자가 submit.example 이 정확하고 인증서와 체인이 해당 엔드포인트에 대한 해당 요구 사항을 충족한다고 확인하면 승인된 클라이언트 구성 수정을 통해 불일치가 해결될 수 있습니다. 엔드포인트는 정확하지만 인증서가 잘못된 경우 대신 서비스 인증서를 복구하세요. 두 경로 모두에서 유효성 검사를 활성화한 상태로 유지하고 수정 후 동일한 서비스를 다시 확인하십시오.
이는 실행된 핸드셰이크, 인증서 발급 또는 청구된 TLS 버전이 아닌 가상의 결정 트리입니다. MX 전달의 경우 제출 클라이언트 가정을 가져오는 대신 실제 MTA-STS 또는 DANE ID 규칙을 사용합니다. HTTPS 홈페이지 인증서는 SMTP 끝점의 인증서나 정책을 설정하지 않습니다.
보호를 삭제하지 않고 원인을 수정하세요
서비스 소유자에게 인증서 갱신 및 체인 배포를 할당하고, 메일 플랫폼 소유자에게 프로토콜 호환성을 할당하고, 네트워크 팀에 차단 또는 경로 중단을 할당합니다. 인증서를 교체하기 전에 예상되는 MX ID와 해당 정책을 확인하세요. 한 번에 하나의 승인된 수정을 수행하고 롤백 계획을 보존하십시오.
단지 테스트 통과를 위해 인증서 경고를 우회하거나 시행을 비활성화하거나 일반 텍스트를 허용하지 마십시오. 발신자가 대체할 수 있는지 여부는 프로토콜과 관리 정책에 따라 다릅니다. 엄격한 정책은 불안정하게 전달되기보다는 의도적으로 연기될 수 있습니다. 안전하지 않은 재시도가 성공하더라도 TLS 문제가 해결되었음을 보여주지는 않습니다.
다시 시작된 SMTP 세션 확인
RFC 3207 에서는 STARTTLS 성공 후 TLS 이전 SMTP 지식을 폐기해야 합니다. 클라이언트가 보내야 할 것 EHLO 먼저 이전 목록과 다를 수 있는 보호된 세션의 기능을 검색합니다. 실제 확인 MTA 이 전환을 완료한 다음 승인된 메시지를 전송합니다. 지속적인 대기열 지연과 최종 결과를 핸드셰이크 성공과 별도로 기록합니다. TLS 전송 홉을 보호합니다. 그 자체로는 눈에 보이는 작성자의 적법성, 엔드투엔드 콘텐츠 기밀성 또는 받은 편지함 배치를 확립하지 않습니다.
TLS 복구하는 동안 보안 요구 사항 유지
- 엔드포인트, 포트, STARTTLS 또는 암시적 모드 및 정확한 실패 단계를 캡처합니다.
- 인증서를 변경하기 전에 활성 정책과 예상 ID를 식별하십시오.
- 별도의 이름, 유효성, 신뢰 체인 및 프로토콜 오류; 로그에서 비밀을 제외합니다.
- 검증을 비활성화하지 않고 승인된 원인별 수리를 적용합니다.
- 정책 준수 TLS , STARTTLS 이후 상태 재설정 및 메시지 결과를 독립적으로 확인합니다.