Thunderbird (및 다른 많은 클라이언트에서도 가정)에는 "SSL / TLS"와 "STARTTLS"중에서 선택할 수있는 옵션이 있습니다.
내가 이해하는 한 "STARTTLS"는 간단한 말로 "양쪽 끝이 TLS를 지원하면 암호화하고 그렇지 않으면 전송을 암호화하지 않음"을 의미 합니다. "SSL / TLS"는 간단한 말로 "항상 암호화하거나 전혀 연결하지 않음"을 의미 합니다. 이 올바른지?
또는 다른 말로하면 :
STARTTLS는 SSL / TLS보다 안전하지 않습니다. 알림없이 일반 텍스트로 대체 될 수 있습니까?
답변:
SMTP 용 STARTTLS RFC ( RFC 3207 ) 에 따른 답변 은 다음과 같습니다.
직접 대화하는 대신 BOLD 에서 강조 표시된 4 개의 관련 비트를 사용하여 RFC가 스스로 대화 할 수 있도록합니다 .
서버에서 "250 STARTTLS"응답을 삭제하여 MITM (Man-in-the-Middle) 공격을 시작할 수 있습니다. 이로 인해 클라이언트는 TLS 세션을 시작하지 않습니다. 또 다른 중간자 공격은 서버가 STARTTLS 기능을 발표 할 수 있도록 허용하지만 클라이언트의 TLS 시작 요청 및 서버 응답을 변경하는 것입니다. 두 클라이언트와 서버가 반드시 같은 공격을 방어하기 위해 할 수 메시지가 성공적으로 전송하기 전에 선택한 호스트에 대한 적절한 암호화 제품군의 성공적인 TLS 협상을 요구하도록 구성된다. 가능한 경우 TLS를 사용 하는 추가 옵션 도 제공해야합니다. 구현 월 TLS가 주어진 피어와 통신하고 이후 세션에서 사용되지 않을 경우 경고를 생성하는 데 사용되었음을 기록하는 기능을 제공합니다.
TLS 협상이 실패하거나 클라이언트가 454 응답을 수신하면 클라이언트는 다음에 수행 할 작업을 결정해야합니다. 세 가지 주요 선택 사항이 있습니다. SMTP 세션의 나머지 부분으로 진행하십시오 . [...]
보시다시피 RFC 자체는 클라이언트가 보안 연결을 설정하고 보안 연결이 실패한 경우 사용자에게 알리지 않아도된다고 말합니다. 그것은 명시 적으로 고객에게 자동으로 설정할 수있는 옵션이 제공 일반 텍스트 연결을.
두 옵션 사이의 보안에는 차이가 없습니다.
SSL / TLS는 먼저 SSL / TLS 연결을 연 다음 SMTP 트랜잭션을 시작합니다. SSL / TLS 이외의 SMTP 서버가 이미 실행되고 있지 않은 포트에서 발생해야합니다. 프로토콜의 특성으로 인해 일반 텍스트와 암호화 된 연결을 모두 처리하도록 단일 포트를 구성 할 수 없습니다.
STARTTLS는 SMTP 트랜잭션을 시작하고 EHLO에 대한 응답으로 다른 쪽 끝에서 TLS에 대한 지원을 찾습니다. 클라이언트가 지원되는 명령 목록에서 STARTTLS를 발견하면 STARTTLS를 전송하고 암호화 협상을 시작합니다. 이 모든 것은 표준 SMTP 포트 25에서 발생하며, 부분적으로 이전 버전과의 호환성을 위해 지원하지만 엔드 포인트간에이를 지원하지만 반드시 요구하지는 않는 기회 주의적 암호화를 허용합니다.
일반적으로 SSL / TLS는 최종 클라이언트와 서버간에 만 사용됩니다. STARTTLS는 서버 간 전송을 보호하기 위해 MTA간에 더 일반적으로 사용됩니다.
이러한 두 가지 구현을 고려할 때 사용자 또는 관리자가 연결이 암호화되었다고 가정하지만 실제로 암호화를 요구하도록 구성하지 않은 경우 STARTTLS는 안전하지 않은 것으로 해석 될 수 있습니다. 그러나 사용 된 암호화는 SSL / TLS와 정확히 동일하므로 이러한 유형의 구성 오류를 넘어 중간자 (Man-in-the-Middle) 공격에 다소 취약하지 않습니다.
특히 이메일의 경우 2018 년 1 월 RFC 8314 가 릴리스되었으며, 이는 IMAP, POP3 및 SMTP 제출을위한 STARTTLS 메커니즘보다 "암시 적 TLS"를 우선적으로 사용하도록 권장합니다.
간단히 말해이 메모는 다음을 권장합니다.
- TUA 버전 1.2 이상은 MUA와 메일 전송 서버 사이, 그리고 MUA와 메일 액세스 서버 사이의 모든 트래픽에 사용됩니다.
- MUA 및 MSP (Mail Service Provider)는 (a) 메일 액세스 및 메일 제출에 일반 텍스트 프로토콜 사용을 권장하지 않으며 (b) 가능한 빨리 이러한 목적으로 일반 텍스트 프로토콜을 사용하지 않습니다.
- 메일 전송 서버 및 메일 액세스 서버 에 연결하려면 "일반 텍스트"포트에 연결하고 STARTTLS 명령 또는 유사한 명령을 사용하여 TLS를 협상 하는 것 보다 "암시 적 TLS"(아래 정의 참조)를 사용하십시오 .
(강조 추가)
대답은 "안전한"의 의미에 어느 정도 달려 있습니다.
먼저 요약에서 SSL / TLS와 STARTTLS의 차이점을 파악하지 못합니다.
클라이언트가 TLS를 요구하도록 구성된 경우, 두 가지 접근 방식은 다소 안전합니다. 그러나 안전을 위해 STARTTLS를 어떻게 사용해야하는지에 대한 미묘한 점이 있으며 STARTTLS 구현에서 이러한 세부 정보를 올바르게 얻는 것이 조금 더 어렵습니다.
반면에 클라이언트가 TLS를 사용할 수있는 경우에만 TLS를 사용하도록 구성되고 TLS를 사용할 수없는 경우 일반 텍스트를 사용하는 경우 클라이언트가 먼저 수행 할 수있는 작업은 프로토콜이 사용하는 SSL 포트에 연결을 시도하는 것입니다. 실패한 다음 일반 텍스트 포트에 연결하고 STARTTLS를 사용 해보고 TLS를 사용할 수없는 경우 일반 텍스트로 돌아갑니다. 공격자가 SSL 포트 연결을 실패시키는 것은 상당히 쉽습니다 (시간이 걸리는 TCP RST 패킷 또는 SSL 포트 차단 만 있으면됩니다). 공격자가 STARTTLS 협상을 물리 치고 트래픽을 일반 텍스트로 유지하는 것은 조금 어렵지만 조금만 어렵습니다. 그런 다음 공격자는 전자 메일을 읽을뿐만 아니라 나중에 사용할 수 있도록 사용자 이름 / 암호를 캡처합니다.
따라서 간단한 대답은 이미 이메일을 보내거나 읽을 때와 같이 TLS를 지원하는 서버에 연결하는 경우 SSL / TLS를 사용해야한다는 것입니다. 연결이 공격을 받으면 연결 시도는 실패하지만 암호와 이메일은 손상되지 않습니다.
반면, TLS를 지원하는지 여부를 모르는 일부 서비스에 연결하는 경우 STARTTLS가 약간 더 나을 수 있습니다.
STARTTLS가 발명되었을 때, "수동적"청취 전용 공격은 매우 일반적이며 공격자가 보안을 낮추기 위해 트래픽을 주입하는 "활성"공격은 덜 일반적이었습니다. 그 이후로 20여 년 동안 활발한 공격이 더욱 실현 가능해졌으며보다 일반적이되었습니다.
예를 들어, 공항이나 다른 공공 장소에서 랩톱을 사용하려고 시도하고 제공된 Wi-Fi를 통해 메일을 읽으려고 시도하는 경우 해당 Wi-Fi 네트워크가 트래픽에 어떤 영향을 미치는지 알 수 없습니다. Wi-Fi 네트워크가 특정 종류의 트래픽을 "프록시"로 라우팅하여 클라이언트 응용 프로그램과 통신하려는 서버 사이에 자신을 배치하는 것이 일반적입니다. 이러한 프록시가 클라이언트가 일반 텍스트로 돌아가도록 시도하기 위해 STARTTLS를 비활성화하고 "한 포트를 다른 포트로 시도"하는 것은 쉽지 않습니다. 예, 이런 일이 발생하며 이는 네트워크에서 트래픽을 감시하는 방법의 한 예일뿐입니다. 그리고 그러한 공격은 3 글자 국가 지원 기관으로 제한되지 않습니다.
네, 기본이 맞습니다. 그리고 예, STARTTLS는 확실히 덜 안전합니다. 통지없이 일반 텍스트로 장애 복구 할 수있을뿐만 아니라 중간자 공격의 대상이되기 때문입니다. 연결이 깨끗하게 시작되기 때문에 MitM은 STARTTLS 명령을 제거하고 암호화가 발생하지 않도록 할 수 있습니다. 그러나 메일 서버는 암호화 된 터널이 설정된 후에 만 전송이 이루어 지도록 지정할 수 있다고 생각합니다. 따라서이 문제를 해결할 수 있습니다.
그렇다면 왜 그런 것이 존재합니까? 호환성을 위해. 어느 쪽이 암호화를 지원하지 않는 경우에도 연결이 제대로 완료되기를 원할 수 있습니다.
아니요, 응용 프로그램이 올바르게 처리 할 때 덜 안전 하지는 않습니다 .
TLS를 처리하기위한 4 가지 방법이 있으며 많은 프로그램에서 선택할 수 있습니다.
starttls, 실패하면 암호화되지 않은 연결 사용)starttls작동하지 않으면 사용 및 실패)전용 포트에서 TLS의 장점은 아직 모르는 프로그램을 사용하거나 첫 번째 시작 마법사에서 오류 처리를위한 세부 설정을 표시하지 않는 폴 백이 없다는 것을 확신 할 수 있다는 것입니다.
그러나 일반적으로 보안은 보안 오류 처리에 달려 있습니다. TLS 포트의 TLS도 실패하면 프로그램이 일반 텍스트 포트로 전환하도록 결정할 수 있습니다. 수행 할 작업을 알고 안전한 설정을 선택해야합니다. 그리고 프로그램은 안전한 기본값을 사용해야합니다.