SMTP 서버의 SSL 인증서에는 어떤 호스트 이름이 포함되어야합니까?

192.0.2.1에 서버 foo.example.com이 있습니다.

내 도메인 중 일부에 대한 전자 메일을 받기 위해 exim을 실행합니다.

내 도메인에는 각각 mx.example.com을 가리키는 MX 레코드가 있으며 이는 192.0.2.1로 해결됩니다.

exim이 수신 이메일 연결에 대해 TLS 암호화를 제공하도록하려면 SSL 인증서에 어떤 호스트 이름을 입력해야합니까?

• foo.example.com 서버가 HELO에서 무엇을 말할까요?
• mx.example.com 이것은 클라이언트가 연결할 호스트 이름이기 때문에?

http://www.checktls.com 은 후자가 정확하다고 제안하지만 결정적인 답변을 찾을 수 없습니다.

이것은 실제로 어느 곳에서나 명시 적으로 정의되어 있지 않으며, 서버의 "신뢰"여부는 클라이언트 (물론 다른 메일 서버 일 수 있음)에 연결된 서버에 따라 다릅니다. 관련 RFC에서 인용 ( RFC 2487 ) :

SMTP 클라이언트가 인증 또는
개인 정보 수준이 계속하기에 충분하지 않다고 판단
하면 TLS 협상이 완료된 직후에 SMTP QUIT 명령을 실행해야합니다.
SMTP 서버가 인증 또는
프라이버시 수준이 계속하기에 충분하지 않다고 판단 하면 554 응답 코드 (예 : 텍스트 문자열
)를 사용
하여 클라이언트의 모든 SMTP 명령 (QUIT 명령 제외)에 응답해야합니다. "
보안 부족으로 인해 명령이 거부되었습니다").

TLS 협상에서 상대방 의 진위 여부에 대한 결정은 현지 문제입니다. 그러나
결정에 대한 몇 가지 일반적인 규칙은 다음과 같습니다.

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

이것이 기본적으로 의미하는 것은 서버가 주어진 인증서를 사용하여 TLS 암호화를 제공 할 때 인증서 수락 또는 거부에 대한 결정은 전적으로 다른 부분에 달려 있으며 인증서의 이름이 연결된 것과 동일하기를 원할 것 입니다. 일치하지 않더라도 아주 잘 받아들입니다.

그러나 더 많은 것이 있습니다. 동일한 RFC에서 다시 인용 :

TLS 핸드 셰이크가 완료되면 SMTP 프로토콜이
초기 상태 (서버에서 220
서비스 준비 인사말을 발행 한 후 SMTP의 상태 )로 재설정됩니다 . 서버 는 TLS 협상 자체에서 얻지 못한
EHLO 명령에 대한 인수와 같이 클라이언트에서 얻은 모든 지식을 폐기해야
합니다. 클라이언트 는 TLS 협상 자체 에서 얻지 못한 SMTP 서비스 확장
목록과 같이 서버에서 얻은 모든 지식을 폐기해야 합니다. 클라이언트는 성공적인 TLS 협상 후 EHLO 명령을 첫 번째 명령 으로 보내야합니다 .

따라서 TLS 핸드 셰이크 이전 의 HELO / EHLO에 대한 서버의 말은 실제로 중요하지 않은 것 같습니다.

필자의 경험에 따르면 자체 서명 인증서는 인터넷 연결 메일 서버에서 잘 작동합니다. 즉, 다른 메일 서버는 인증서 확인에도 신경 쓰지 않으며 발급에 관계없이 TLS 암호화를 제공 할 수있는 모든 것을 행복하게 받아들입니다. 권한 또는 주제 이름.

도메인에 메일을 배달하는 MTA는 MX 레코드 (호스트 이름 생성)를 조회 한 다음 해당 호스트 이름에 대한 A 레코드를 조회합니다. 따라서 연결되는 호스트 이름은 MX 호스트 이름이므로 SSL 인증서 공통 이름과 비교하여 확인됩니다. 서버가 원하는 HELO 호스트 이름을 제공 할 수 있기 때문에 HELO 호스트 이름을 확인하는 것은 의미가 없습니다. 추가 보안을 제공하지는 않습니다.

즉, 메일을 전달할 때 SSL 인증서를 엄격하게 확인하는 것은 현재로서는 특히 유용하지 않습니다. MTA는 SSL이 아닌 배달로 대체 될 것이기 때문입니다. 이는 SMTP가 현재 작동하는 방식이기 때문입니다. 따라서 합리적인 구성은 SSL 인증서의 검증 여부에 관계없이 MX 서버가 SSL을 제공하는 경우 SSL을 사용하는 것입니다 (인증이없는 암호화가 암호화가없고 인증이없는 것보다 낫기 때문에). 따라서이 목적으로 자체 서명 된 인증서를 사용할 수도 있습니다.

서버 인증서를 확인하고 서버의 호스트 이름과 일치하는 작업은 SSL / TLS를 사용하는 모든 프로토콜에 대한 클라이언트의 역할입니다.

따라서 인증서의 호스트 이름은 클라이언트가 액세스하려는 이름과 일치해야합니다.

SSL / TLS 연결이 시작될 때 (SMTPS), 서버는 연결이 설정되기 전에 HELO 메시지가 무엇을 말하는지 알 수 없으므로 요청과 함께 사용되어야합니다.

이후 SSL / TLS를 사용할 때 STARTTLS클라이언트는 여전히 구성된 서버와 통신하려고하므로 여전히 확인해야합니다. MITM 공격을 가능하게하는 실패 :

• C-> S : 안녕하세요, 저는 Alice입니다. Bob과 이야기하고 싶습니다.
• S-> C : 안녕하세요, 저는 척입니다. 여기 척에 대한 증명서가 있습니다.
• C-> S : 네, 그렇습니다. 인증서는 척에 유효합니다. 계속합시다.
• ... Alice가 Bob과의 안전한 통신을 원했기 때문에 물론 결함이 있습니다.

두 경우 모두 사용해야하는 MX 주소입니다.

호스트 이름 일치 규칙은 최근에 RFC 6125의 프로토콜에 걸쳐 수집 되었지만 완전히 구현하지 않는 클라이언트는 거의 없습니다 (완전한 변경보다 RFC가 더 우수하며 여전히 최신입니다).

에서 의 부록 , 그것은 (에서 촬영하기 전에 SMTP에 대해 존재했던 요약 RFC 3207 및 RFC 4954 ). 특히 " 클라이언트는 안전하지 않은 원격 소스 (예 : 안전하지 않은 DNS 조회)에서 파생 된 어떠한 형태의 서버 호스트 이름도 사용해서는 안됩니다. "(물론 서버 배너에 적용됨). 이 외에도에서의 SMTP 레거시 규칙은 주체 대체 이름 (대한 좀 더 HTTPS보다 완화했다 해야 대신 합니다 사용).

현대적인 방법은 호스트 이름을 주제 대체 이름 DNS 항목에 넣는 것입니다. 와일드 카드 사용도 권장하지 않습니다 .

실제로 최선을 다하는 것이 최선이라고 생각합니다. http://checktls.com을 사용하여 yahoo.com 이메일 주소를 확인 했습니다. yahoo에서 호스트 이름과 mx 도메인에 다른 도메인을 사용했으면합니다. 따라서 호스트 이름은 yahoo.com이며 mx 도메인은 yahoodns.net으로 끝납니다.

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others

점검 결과 : SSL 인증서 CN = MX 도메인 (* .yahoodns.net)

나는 시스코와 똑같이했고 같은 결과를 얻었습니다.

SSL / TLS 암호화에서 클라이언트는 항상 원격 시스템의 "실제"/ "선언 된"호스트 이름과 인증서에 포함 된 정보 간의 일치 성을 확인합니다.

따라서 foo.example.com을 설정하거나 와일드 카드 인증서를 생성해야합니다. ;-)