요약

  • RFC 8314는 메일 접근 및 제출에 암묵적 TLS를 권고합니다. 465, 993, 995와 같은 포트에서는 애플리케이션 계층 업그레이드 명령을 기다리지 않고 TCP 연결 직후 TLS 핸드셰이크가 시작됩니다.
  • 이 선택은 채널 수립 경로를 보호할 뿐입니다. 그것만으로 의도한 서비스를 검증하거나, 사용자를 인증하거나, 메일함 또는 발신자 권한을 부여하거나, 메시지 수락을 증명하거나, 최종 전달을 증명하지는 않습니다.

문제 해결 메모에는 "보안 연결됨"이라는 말만 있었습니다. 클라이언트는 465번 포트를 향했고, 자물쇠 아이콘이 표시되었으며, TLS 핸드셰이크는 완료되었습니다. 그런데도 서버는 발신자 주소를 거부했습니다. 이 관찰들 사이에 모순은 없습니다. 보안 포트는 대화가 시작되는 방식을 정했고, 이후 정책 결정이 인증된 계정이 무엇을 할 수 있는지 정한 것입니다.

이 구분을 잃기 쉬운 이유는 메일 클라이언트가 일련의 기술적 결정을 초록색 기호 하나로 압축하기 때문입니다. 구성된 서비스 이름은 주소가 되고, 주소와 포트는 TCP 연결이 되며, TLS 교환은 암호 매개변수를 협상하고 인증서를 제시합니다. 클라이언트는 서비스 신원을 검증하고, 애플리케이션 메커니즘은 자격 증명을 인증합니다. 서버는 그 신원을 계정에 매핑하고 메일함, 발신자 또는 명령이 승인되었는지를 결정합니다. 모든 단계가 성공하더라도 다음 단계는 실패할 수 있습니다.

Keith Moore와 Chris Newman은 2018년에 RFC 8314를 발표했습니다. 이 문서의 핵심 운영 입장은 더 이상 평문이 메일 사용자 에이전트와 메일 접근·제출 서버 간 통신의 정상 전송 방식이 되어서는 안 된다는 것입니다. 평문으로 애플리케이션 세션을 연 뒤 STARTTLS 등 유사 명령으로 보호를 협상하는 방식보다 POP, IMAP, SMTP 제출에 암묵적 TLS를 권고합니다.

"암묵적(implicit)"은 숨겨진 보안이 아니라 시점을 뜻합니다. 클라이언트가 기본 포트 465의 submissions 서비스를 열면 TLS 핸드셰이크가 즉시 시작됩니다. IMAP의 993, POP의 995도 마찬가지입니다. TLS가 수립된 후에야 애플리케이션 프로토콜이 그 연결에서 진행됩니다. 반면 STARTTLS에서는 클라이언트가 먼저 평문 TCP 연결에서 애플리케이션 프로토콜을 사용하고, 업그레이드 기능을 발견한 뒤 핸드셰이크 전에 업그레이드 명령을 발행합니다.

이 차이는 암묵적 경로에서 TLS 이전 명령 단계를 제거할 뿐입니다. 465번 포트를 암호학적 사실로 만들지는 않습니다. 포트는 연결 수립에 대한 입력일 뿐이며, 잘못 레이블된 서비스나 리다이렉트된 주소, 예상치 못한 프로토콜을 실행하는 리스너는 목적지 번호가 익숙하다고 신뢰할 수 없습니다. 근거는 의도한 서비스에서 시작해 실제 도달한 엔드포인트와 실제 관찰된 핸드셰이크까지 이어집니다.

RFC 8314는 설치된 시스템이 즉시 전환할 수 있다고 가정하지 않았습니다. 제출 포트 587에 STARTTLS가 널리 배포되어 있음을 언급하면서, 전환 기간 동안 클라이언트와 서버가 STARTTLS를 사용하는 587과 암묵적 TLS를 사용하는 465를 모두 지원하도록 권고합니다. 핵심은 보호된 전송을 요구하는 정책이며, 모든 STARTTLS 구현이 본질적으로 안전하지 않다는 주장이 아닙니다. RFC 2595는 이미 IMAP, POP3, ACAP에 대한 STARTTLS를 명시하며 결정적인 경고를 담고 있었습니다. 공격자는 광고된 업그레이드 기능을 제거하거나 업그레이드 실패를 유발할 수 있다는 것입니다. 그것이 다운그레이드가 되는지는 클라이언트가 다음에 무엇을 하느냐에 달려 있습니다. TLS를 요구하도록 구성된 클라이언트는 조용히 계속 진행해서는 안 됩니다.

핸드셰이크 자체에도 이름이 필요합니다. RFC 8314는 암묵적 TLS 서비스의 클라이언트에 인증서 검증 구현을 요구합니다. 다른 저자들이 작성한 RFC 9525의 현재 일반 프레임워크는 그 근거 경계를 설명합니다. 클라이언트는 신뢰할 수 있는 구성이나 입력으로부터 하나 이상의 참조 식별자를 구성하고, 서버 인증서에서 제시된 식별자를 받아, 인증 경로를 검증하고 허용되는 일치를 찾습니다. 과정에서 발견된 주소가 클라이언트가 인증하려던 신원인 것은 아닙니다.

성공적인 일치는 그 절차의 범위에서 애플리케이션 서비스 신원을 수립할 뿐입니다. 클라이언트를 운영하는 사람을 식별하지 않고, 서비스가 선의적이거나 올바르게 구성되었거나 검증된 집합을 넘는 모든 호스트명에 대한 권리가 있음을 증명하지도 않으며, 사용자의 메일함 접근을 부여하지도 않습니다. TLS 채널의 서버 측과 애플리케이션 세션의 사용자 측은 다른 주체입니다.

클라이언트 인증서는 이 그림을 복잡하게 만들 수 있지만 지우지는 못합니다. RFC 8314는 메일 서버가 클라이언트 인증서 인증을 지원할 수 있도록 허용하면서도, 인증서가 제공된 경우에도 애플리케이션 수준 인증을 요구할 수 있도록 허용합니다. 따라서 운영자는 상호 TLS 기록만으로 사용자 승인을 추론할 수 없습니다. 서비스가 인증서 또는 이후 자격 증명을 어떤 애플리케이션 신원에 매핑했고 어떤 정책이 그에 부착되었는지가 여전히 문제입니다.

SASL은 이 구분을 명시적으로 만듭니다. RFC 4422는 자격 증명에 연결된 인증 신원과 클라이언트가 위임받기를 요청하는 승인 신원을 분리합니다. 서버는 자격 증명을 검증하고, 인증된 신원이 요청된 승인 신원으로서 행동할 수 있는지를 결정해야 합니다. 어느 한쪽이 실패하면 교환은 실패합니다. 클라이언트가 별도의 승인 문자열을 생략하면 보통 자기 자신으로서 행동할 것을 요청하며, 이 기본값은 서버의 정책 결정을 제거하지 않습니다.

메일 제출은 또 다른 승인 표면을 더합니다. RFC 6409는 제출과 릴레이를 분리하고 포트 587을 메시지 제출용으로 예약합니다. 메시지 제출 에이전트(MSA)는 승인된 사용자를 요구하고, 로컬 규칙을 시행하며, 충분한 제출 권한이 없거나 사용된 인증과 불일치하는MAIL FROM신원을 거부할 수 있습니다. 보호된 세션이 MSA에 도달했다는 사실은 어떤 서비스에 접촉했는지를 말할 뿐입니다. 봉투 발신자, 수신자, 메시지 크기 또는 기타 정책 통제 작업을 사전 승인하지는 않습니다.

성공적인 제출 응답조차 의미가 제한적입니다. 그것은 프로세스의 그 시점에서 MSA가 책임을 수락했음을 기록합니다. 이후의 전송, 수신 서버 응답, 필터링, 메일함 배치, 사람의 읽기는 모두 하류에 있습니다. "TLS 성공", "사용자 인증됨", "제출 수락됨", "메시지 전달됨"은 서로 다른 네 가지 영수증입니다.

따라서 방어 가능한 기록은 자물쇠가 아니라 순서를 보존합니다. 클라이언트의 구성된 서비스 이름과 검색 입력으로 시작하고, 확인된 주소와 접촉한 포트를 기록하며, 이어서 TLS 시작 모드, 기록 내역, 협상된 버전, 피어 인증서를 보존합니다. 신뢰 경로, 참조 식별자, 제시된 식별자 일치를 기록합니다. 그 다음에는 SASL 메커니즘, 인증 신원, 요청된 승인 신원, 서버 결정, 애플리케이션 명령, 정확한 응답이 옵니다. 발신 메일의 경우 전송과 전달 근거는 이후의 사슬을 형성합니다.

Newman과 Moore의 기여가 중요한 이유는 보호를 앞으로 당겨오면서도, 앞선 핸드셰이크가 이후 모든 질문에 답한다고 가장하지 않기 때문입니다. 암묵적 TLS는 보안 전송을 첫 번째 프로토콜 행위로 만들 수 있습니다. 승인은 여전히 계정과 작업을 통제하는 서비스에 속합니다.

출처