이메일을 보내고받을 때 가능한 경우 TLS를 사용하도록 현재 설정된 이메일 서버를 실행 중입니다.
이것에 관한 문서를 읽으면 TLS를 시행하고 전자 메일의 일반 텍스트 전송을 허용하지 않는 옵션도 있습니다. 또한 일부 메일 서버는 아직 암호화를 지원하지 않을 수 있으며 암호화를 시행하면 이러한 서버가 차단 될 수 있음을 경고합니다.
그러나 이것은 여전히 암호화해야 할 문제이거나 암호화 시행이 더 이상 문제가되지 않는다고 말하는 것이 안전합니까?
이미이 일을하고있는 큰 공급자가 있습니까? 아니면 요즘 가장 좋은 방법은 무엇입니까?
답변:
실질적인 문제는 모든 SMTP 호환 (RFC가 매우 오래된) 서버가 서버와 TLS를 통신 할 수있는 것은 아니므로 일부 전자 메일 메시지를받지 못할 수도 있습니다.
이것의 철학적 문제는 이메일이 서버에 도착한 후 (또는 이전에) 어떻게 릴레이되는지 알 수 없다는 것입니다.
이는 이메일이 이미 릴레이를 통해 일반 텍스트로 전송되었을 수 있음을 의미합니다.
전자 메일 내용을 보호하는 데 관심이있는 사람은 실제로 본문을 암호화해야합니다. 암호화 en-route를 사용하면 항상 평범한 텍스트로 전송됩니다.
따라서 SMTP 계층에서 암호화를 시행하는 질문에 답하는 것은 의미가 없으며 전자 메일이 누락 될 가능성이 높아지고 유익한 보상이 보장되지 않습니다.
편집 : 전자 메일 제출이 아닌 릴레이 목적으로 SMTP를 시행하는 것을 말합니다 . 메일 제출시 SMTP 대화 (실제 이메일이 아님)에 인증 자격 증명이 포함되어 있으므로 암호화를 시행해야합니다.
아니
RFC 821은 33 세입니다. STARTTLS를 지원하지 않는 프로그램에서 릴레이 된 이메일 을 찾을 수 있습니다. 때때로 그들은 이메일 발신자 (예 : 내부 스크립트), 때로는 오래된 본격적인 시스템, TLS를 비활성화 / 컴파일하지 않은 시스템, 엔트로피가 충분하지 않은 시스템 등…
수신 측에서 SMTP over TLS 만 허용하도록 구성 되었기 때문에 오래 전에 아웃 바운드 이메일이 실패하는 것을 목격했습니다. 발신자에게 문제가 있었지만 (해당 구성을 사용해서는 안 됨) 발생했음을 보여줍니다.
수동으로 구성된 IP 주소에서 들어오는 메시지 만 제한합니다. 신용 카드 프로세서가 STARTTLS를 시작하지 못하면 암호화되지 않은 (잠재적으로 민감한) 데이터를 수신하는 것보다 연결을 중단하고 로컬 관리자에게 경고 할 수 있습니다. 아웃 바운드 메시지의 경우, 이전에 STARTTLS를 사용하여 해당 호스트에 연결 한 경우이를 잠재적으로 타협으로 취급하여 안전하지 않은 상태로 다시 수행하지 않을 수 있습니다. gmail 또는 yahoo와 같이 알려진 항상 사용하는 STARTTLS 호스트 목록이있을 수도 있습니다.
https://www.eff.org/starttls-everywhere 프로젝트 에는 starttls 사용을 자신있게 적용 할 수있는 smtp 서버 목록이 제공됩니다.
암호화가 불가능한 피어의 전자 메일을 거부하는 것은 완전히 의미가 없으며 아마도 적극적으로 해 롭습니다.
서버가 서버를 제공하는 다른 피어와의 기회 적 암호화를 수행하도록 설정되어 있으면 사용 가능한 암호화 및 사용 불가능한 경우 일반 텍스트를 통한 전자 메일을 모두 사용할 수 있습니다.
암호화를 지원하지 않는 서버가있는 한,이를 관리한다는 것은 단순히 사용자와 대화 할 수 없다는 것을 의미합니다. 그 나쁜. 모든 사람이이를 지원하면 기회 암호화와 필수 암호화간에 차이가 없습니다.
그리고 다른 사람들이 지적했듯이, 온-와이어 암호화와 엔드 투 엔드 암호화는 서로 다른 위협 모델을 다루는 완전히 다른 두 가지입니다. 둘을 혼동하지 마십시오.
아니요, 매우 나쁜 생각입니다.
실제로, 대부분의 STARTTLS 서버 / 클라이언트는 TLS 연결이 협상에 실패 할 경우 StartTLS가 없으면 어떤 종류의 재시도 알고리즘도 구현하지 않습니다.
따라서 STARTTLS를 옵션으로 광고하는 것조차도 이미 이메일 수신 및 전송 가능성을 줄입니다!
검색 만하면 * .protection.outlook.com 클러스터에서 처리하는 Microsoft Outlook 도메인으로 이메일을 보낼 수없는 많은 사람들이 있습니다.
TLS를 사용할 때 Microsoft에서 보낸 메일 메시지가 거부 됨
위의 두 게시물에 제시된 문제를 요약하면 다음과 같습니다.
마찬가지로 호스트가 서버로 작동 할 때 STARTTLS를 사용하기로 결정한 경우 유사한 상황이 제어 범위를 벗어나서 발생할 수 있습니다. 클라이언트 서버가 서버 모드의 서버에서 STARTTLS를 제공하는 것으로 확인되면 TLS 협상을 시도하지만 협상에 실패하면 , 그들은 단순히 기다렸다가 동일한 단계를 다시 시도하고, 메시지가 발신자에게 반송 될 때까지 계속 실패합니다!
그리고 이것은 STARTTLS 땅의 다양한 도메인에서 자주 발생합니다!
슬프게도, 과거에 STARTTLS 후원자였던 것처럼, 나는 기회 주의적 암호화라고 생각되는 것의 위험이없는 광고로 인해 잘못 인도되었다는 사실을 매우 소외합니다.
상호 운용성을 보장하려면 STARTTLS가 필요하지 않을뿐만 아니라 완전히 비활성화하는 것이 현명 할 수도 있습니다.
기회 주의적 TLS를 사용한다는 아이디어에 동의해야합니다. 그래도 아이디어에 추가해야 할 것이 있습니다. 그러나 여기에 내 제안이 가볍게 고려되지 않고 판단되지 않기 때문에 일부는 제안에 의해 방해받을 수 있습니다. 첨부 된 링크에서 전체 토론을 읽으십시오.
기회 주의적 TLS를 사용하는 것이 지금까지 최고의 솔루션입니다. MITM 각도에 대한 논거는 빨간 청어입니다. 결국 MH가 의견에서 언급했듯이 TLS 연결을 갖춘 "legit"SMTP조차도 MITM 될 수 있으며 대다수의 메일 클라이언트는 대다수와 결합 된 인증서의 유효성 검사를 귀찮게하지 않기 때문에 최종 사용자가 더 현명하지 않습니다. TLS를 수행하는 MTA는 자체 서명 된 인증서를 사용하고 있습니다 (적어도 DNSSEC 및 TLSA / DANE를 사용하지 않는 경우).이 결과 및 기타 요인의 결과로, 귀하와 다른 국가에 이르기까지는 논란의 여지가 있습니다. DANE / TLSA 및 DNSSEC를 구현하여 기회주의 TLS를 실행하는 동안 익명의 diffie-hellman (PFS를 사용하는 동안)도 사용하지 않는 것보다 낫습니다. 적어도 부분적으로는 대부분 일반 관찰자로부터 보호하는 트래픽을 여전히 암호화한다는 사실 때문입니다. 이 구성에 대한 추가 지원 (내보다 훨씬 더 자세한 설명으로)이 게시물의 후위 포럼에서 Viktor Dukhovni의 의견을 참조하십시오.http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html
Viktor의 제안을 다른 사람들의 제안보다 더 잘 받아 들일 수있는 이유에 대해, 그는 TLS 코드와 Postfix MTA를위한 TLSA / DANE 코드뿐만 아니라 TLS 코드를 작성했으며 두 DNSSEC에 IETF 초안을 작성한 사람이었습니다. 및 TLSA / DANE. 따라서 나는 그 문제에 관한 그의 말이 아마도 대부분의 것보다 훨씬 많은 무게를 가지고 있다고 말할 것입니다.
도움이 되었기를 바랍니다.