기회주의적 TLS
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
기회주의적 TLS는 기존 평문 통신 포트에서 암호화 통신으로 전환하여 TLS(Transport Layer Security) 또는 SSL(Secure Sockets Layer) 프로토콜을 사용하는 기술이다. 다양한 프로토콜(SMTP, IMAP, POP3 등)에 적용 가능하며, SMTP에서 이메일 전송 보안을 강화하는 데 사용된다. 그러나 초기 핸드셰이크가 일반 텍스트로 이루어져 중간자 공격에 취약하며, 이를 STRIPTLS 공격이라고 한다. 이러한 취약점을 해결하기 위해 SMTP 클라이언트에서 TLS를 필수적으로 사용하도록 설정하거나, DNS 기반 인증(DANE)을 활용할 수 있다. 또한, 전자 메일의 완전성 및 기밀성 확보, 발신자 인증을 위해서는 S/MIME과 같은 상위 계층의 보안 기술이 필요하다.
더 읽어볼만한 페이지
- 인터넷 메일 프로토콜 - 포스트 오피스 프로토콜
포스트 오피스 프로토콜(POP)은 이메일 클라이언트가 서버에서 이메일을 다운로드하는 데 사용되는 인터넷 프로토콜로, 보안 강화를 위해 SASL 인증, TLS 암호화 등의 방법이 사용되지만 폴더 관리나 메시지 상태 추적 기능은 제한적이다. - 인터넷 메일 프로토콜 - 인터넷 메시지 접속 프로토콜
인터넷 메시지 접속 프로토콜(IMAP)은 이메일을 서버에 저장하고 여러 기기에서 동기화하여 접근할 수 있도록 하는 프로토콜로, POP3에 비해 다양한 장점을 가지며 IMAPS와 STARTTLS를 통해 보안 연결을 지원하고 널리 사용된다. - 전송 계층 보안 - 공개 키 기반 구조
공개 키 기반 구조(PKI)는 공개 키 암호화를 기반으로 안전한 통신과 개체 식별을 가능하게 하는 기술로서, 디지털 인증서를 통해 공개 키를 특정 개체에 연결하고 인증서를 관리하며, 인증 기관(CA), 등록 기관(RA) 등 다양한 구성 요소로 이루어져 인증서 발급, 관리, 배포, 사용 및 폐기와 관련된 역할, 정책, 하드웨어, 소프트웨어 및 절차의 집합을 포함한다. - 전송 계층 보안 - HTTPS
HTTPS는 HTTP에 보안 기능이 더해진 통신 규약으로, 웹 브라우저와 서버 간 통신을 암호화하여 보안을 강화하지만, 인증서 비용, 서버 부하, 혼합 콘텐츠 문제 등의 단점도 존재한다.
| 기회주의적 TLS |
|---|
2. 특징
STARTTLS는 암호화 통신을 위해 별도의 TCP 포트를 할당하지 않고, 기존의 평문 통신 포트에서 TLS (Transport Layer Security) 또는 SSL (Secure Sockets Layer)을 이용한 암호화 통신으로 전환하는 방식을 의미한다.[15]
TLS의 주요 장점 중 하나는 특정 애플리케이션 프로토콜에 독립적이라는 점이다. IETF의 RFC 5246 문서에서는 "TLS의 장점 중 하나는 애플리케이션 프로토콜로부터 독립적이라는 것이다. 상위 계층의 프로토콜에서 볼 때 TLS는 투명하다. 그러나 TLS는 표준적으로 보안을 어떻게 구현할 것인지까지 규정하고 있지는 않다. 핸드셰이크를 어떻게 시작할지, 교환된 전자 인증서를 어떻게 해석할지는, TLS보다 상위 계층의 설계 및 구현에 위임되어 있다"고 설명한다.[2][15]
SMTP에서 STARTTLS를 사용하는 예시를 보면(RFC 3207 참고[3]), 클라이언트가 서버에 접속하여 `EHLO` 명령어로 기능을 확인한 후, 서버가 `STARTTLS` 지원을 알리면 클라이언트는 `STARTTLS` 명령어를 보내 TLS 협상을 시작한다. 협상이 성공적으로 완료되면, 이후의 모든 통신은 암호화된 보안 채널을 통해 이루어진다. 예를 들어, 사용자 인증과 같은 민감한 정보 교환이 안전하게 수행될 수 있다.[4]
기회주의적 TLS 사용 외에도, 잘 알려진 프로토콜의 보안 버전을 위해 별도의 TCP 포트를 할당하는 방식(암묵적 TLS)도 존재한다. 이 방식은 연결 시작부터 암호화된 통신을 설정한다. 별도의 SSL 포트를 사용하는 방식은 통신 설정에 필요한 왕복 횟수가 적고, 암호화되지 않은 형태로 전송되는 메타데이터가 적다는 장점이 있다.[5] 주요 프로토콜과 해당 포트는 다음과 같다.
| 프로토콜 | 목적 | 일반 포트 | SSL 변형 | SSL 포트 |
|---|---|---|---|---|
| SMTP | 이메일 전송 | 25/587 | SMTPS | 465 |
| POP3 | 이메일 검색 | 110 | POP3S | 995 |
| IMAP | 이메일 읽기 | 143 | IMAPS | 993 |
| NNTP | 뉴스 리더 | 119/433 | NNTPS | 563 |
| LDAP | 디렉토리 접근 | 389 | LDAPS | 636 |
| FTP | 파일 전송 | 21 | FTPS | 990 |
TLS는 특정 애플리케이션에 얽매이지 않는 독립적인 프로토콜이다. RFC 5246 문서에 따르면 다음과 같다.
STARTTLS는 여러 네트워크 프로토콜에서 TLS 암호화를 시작하는 표준적인 방법 중 하나이다. 각 프로토콜이 STARTTLS를 어떻게 지원하고 구현하는지에 대한 구체적인 기술 명세는 해당 프로토콜별 RFC(Request for Comments) 문서에 정의되어 있다.[2][3]
최소한 이메일 관련 프로토콜(SMTP, POP3, IMAP)의 경우, RFC 8314는 보안성 강화를 위해 STARTTLS 방식보다는 별도의 SSL 포트(암묵적 TLS) 사용을 선호하고 권장한다. STARTTLS는 애플리케이션 프로토콜에 독립적이므로, 위에 언급된 프로토콜 외에도 다양한 환경에서 적용될 수 있다.
3. 레이어링
:TLS의 장점 중 하나는 애플리케이션 프로토콜에 독립적이라는 것이다. 상위 레벨 프로토콜은 TLS 프로토콜 위에 투명하게 레이어링될 수 있다. 그러나 TLS 표준은 프로토콜이 TLS로 보안을 추가하는 방법을 구체적으로 명시하지 않는다. TLS 핸드셰이크를 시작하는 방법과 교환된 인증서를 해석하는 방법에 대한 결정은 TLS 위에서 실행되는 프로토콜의 설계자 및 구현자의 판단에 맡겨진다.[2][15]
이러한 방식은 여러 TLS 라이브러리 구현에서 편리하게 지원하는 레이어 구분 방식과 일치한다. 예를 들어, RFC 3207 SMTP 확장은 클라이언트와 서버가 보안 세션을 시작하는 과정을 다음과 같이 보여준다.[3]
: S: <TCP 포트 25에서 연결 대기>
: C: <연결 시작>
: S: 220 mail.example.org ESMTP 서비스 준비
: C: EHLO client.example.org
: S: 250-mail.example.org 환영 메시지를 보냅니다.
: S: 250 STARTTLS
: C: STARTTLS
: S: 220 진행하세요
: C: <TLS 협상 시작>
: C & S: <TLS 세션 협상>
: C & S: <협상 결과 확인>
: C: EHLO client.example.org[4]
위 대화에서 마지막 `EHLO` 명령은 보안 채널, 즉 TLS 연결 위에서 전송된다. SMTP에서는 인증이 선택 사항인데, 이처럼 보안 채널이 확립된 후에는 서버가 일반 텍스트 응답에서는 광고할 수 없었던 `AUTH PLAIN` 같은 SMTP 인증 확장 기능을 안전하게 알릴 수 있게 된다.
기존의 암묵적인 TLS (또는 SSL) 방식에서는 암호화통신을 위해 별도의 전용 포트를 할당해야 했다. 하지만 STARTTLS를 사용하면 전용 포트 번호 없이도 기존 평문 통신 중간에 암호화 통신으로 전환할 수 있다.
4. 프로토콜별 STARTTLS 지원 (RFC)
4. 1. 주요 프로토콜
TLS는 애플리케이션 프로토콜에 독립적으로 작동한다. RFC 5246에서는 다음과 같이 설명한다.
: TLS의 장점 중 하나는 애플리케이션 프로토콜에 독립적이라는 점이다. 상위 레벨 프로토콜은 TLS 프로토콜 위에 투명하게 계층화될 수 있다. 그러나 TLS 표준은 프로토콜이 TLS로 보안을 추가하는 방법을 구체적으로 명시하지 않는다. TLS 핸드셰이크를 시작하는 방법과 교환된 인증서를 해석하는 방법에 대한 결정은 TLS 위에서 실행되는 프로토콜의 설계자와 구현자의 판단에 맡겨진다.[2]
TLS를 사용하는 방식은 여러 TLS 라이브러리 구현에서 지원하는 레이어 구분 방식과 일치한다. 예를 들어, RFC 3207 SMTP 확장은 클라이언트와 서버가 보안 세션을 시작하는 과정을 보여준다.[3]
서버(S): <TCP 포트 25에서 연결 대기>
클라이언트(C): <연결 시작>
서버(S): 220 mail.example.org ESMTP 서비스 준비
클라이언트(C): EHLO client.example.org
서버(S): 250-mail.example.org 환영의 포옹을 제공합니다.
서버(S): 250 STARTTLS
클라이언트(C): STARTTLS
서버(S): 220 진행하세요
클라이언트(C): <TLS 협상 시작>
클라이언트(C) & 서버(S): <TLS 세션 협상>
클라이언트(C) & 서버(S): <협상 결과 확인>
클라이언트(C): EHLO client.example.org[4]
. . .
위 대화에서 마지막 ''EHLO'' 명령은 보안 채널을 통해 전송된다. SMTP에서는 인증이 선택 사항이며, 이 단계 이후 서버는 일반 텍스트 통신에서는 제공하지 않던 ''AUTH PLAIN''과 같은 SMTP 인증 확장을 안전하게 알릴 수 있다.
주요 프로토콜에서 기회주의적 TLS를 사용하는 방식은 다음과 같은 RFC 문서에 정의되어 있다.
| 프로토콜 | 관련 RFC |
|---|---|
| IMAP, POP3, ACAP | RFC 2595 |
| SMTP | RFC 3207 |
| FTP | RFC 4217 |
| XMPP | RFC 6120 (5절) |
| LDAP | RFC 4511 (4.14절) |
| NNTP | RFC 4642 |
이 중 POP3, IMAP, SMTP에 대해서는 RFC 8314에서 STARTTLS 방식보다 암묵적 TLS(Implicit TLS) 연결 사용을 권장하고 있다.
4. 2. 권고 사항
기회주의적 TLS 사용 외에도, 잘 알려진 프로토콜의 SSL/TLS 보안 버전을 위해 여러 개의 TCP 포트가 정의되어 있다. 이는 처음부터 암호화된 연결(암묵적 TLS)을 설정하여 통신하는 방식으로, 기존의 암호화되지 않은 프로토콜과 동일한 통신 스트림을 제공한다. 별도의 TLS 포트는 STARTTLS 방식에 비해 더 적은 왕복이라는 장점이 있으며, 암호화되지 않은 형태로 전송되는 메타데이터도 적다.[5] 몇 가지 예는 다음과 같다.| 프로토콜 | 목적 | 일반 포트 | SSL/TLS 변형 | SSL/TLS 포트 |
|---|---|---|---|---|
| SMTP | 이메일 전송 | 25/587 | SMTPS | 465 |
| POP3 | 이메일 검색 | 110 | POP3S | 995 |
| IMAP | 이메일 읽기 | 143 | IMAPS | 993 |
| NNTP | 뉴스 리더 | 119/433 | NNTPS | 563 |
| LDAP | 디렉토리 접근 | 389 | LDAPS | 636 |
| FTP | 파일 전송 | 21 | FTPS | 990 |
최소한 이메일 관련 프로토콜(POP3, IMAP, SMTP)의 경우, RFC 8314에서는 STARTTLS 대신 별도의 TLS 포트(암묵적 TLS 연결)를 사용하도록 권고한다.
5. SMTP에서의 STARTTLS
SMTP는 이메일 전송에 사용되는 표준 프로토콜이다. 기본적으로 SMTP 통신은 암호화되지 않지만, STARTTLS 명령을 사용하여 통신 중간에 TLS 암호화를 시작할 수 있다. 이는 IETF RFC 3207에 정의된 SMTP 확장 기능으로,[3][16] 클라이언트와 서버가 통신 중 `STARTTLS` 명령을 교환하여 보안 연결 수립을 시도한다. 협상이 성공하면 이후의 모든 SMTP 명령과 데이터는 암호화된 TLS 채널을 통해 전송되어, 도청이나 데이터 변조로부터 이메일 통신을 보호하는 데 도움을 준다.[4][17]
5. 1. 동작 방식 (예시)
TLS는 특정 애플리케이션 프로토콜에 종속되지 않는다는 특징을 가진다. IETF RFC 5246 문서에서는 이를 다음과 같이 설명한다.[2]: TLS의 장점 중 하나는 애플리케이션 프로토콜에 독립적이라는 것입니다. 상위 레벨 프로토콜은 TLS 프로토콜 위에 투명하게 레이어링될 수 있습니다. 그러나 TLS 표준은 프로토콜이 TLS로 보안을 추가하는 방법을 구체적으로 명시하지 않습니다. TLS 핸드셰이크를 시작하는 방법과 교환된 인증서를 해석하는 방법에 대한 결정은 TLS 위에서 실행되는 프로토콜의 설계자 및 구현자의 판단에 맡겨집니다.
TLS를 사용하는 방식은 여러 TLS 라이브러리 구현에서도 지원된다. 예를 들어, SMTP에서 STARTTLS 확장(IETF RFC 3207)을 사용하는 경우, 클라이언트(C)와 서버(S)는 다음과 같은 과정을 통해 보안 세션을 시작할 수 있다.[3][16]
S: <TCP 포트 25번에서 접속 요청을 대기>
C: <접속을 오픈>
S: 220 mail.example.org ESMTP service ready
C: EHLO client.example.org
S: 250-mail.example.org offers a warm hug of welcome
S: 250 STARTTLS
C: STARTTLS
S: 220 Go ahead
C: <TLS 네고시에이션을 시작>
C & S: <TLS의 네고시에이션>
C & S: <네고시에이션 결과를 확인>
C: EHLO client.example.org
. . .
위 대화에서 마지막 `EHLO` 명령은 암호화된 보안 채널을 통해 전송된다.[4][17] SMTP에서는 인증이 선택 사항이지만, 보안 채널이 형성된 후에는 서버가 일반 텍스트 통신에서는 사용할 수 없었던 `AUTH PLAIN`과 같은 인증 방식을 안전하게 제공할 수 있게 된다.[18]
2011년 10월 기준으로, Gmail[19]과 iCloud[20] 등의 웹 메일 서비스에서 메일 전송 시 STARTTLS를 지원하고 있다.
5. 2. 대한민국 현황
2011년 10월 현재, STARTTLS를 메일 전송에 제공하고 있는 주요 프리 메일 서비스에는 Gmail[19]과 iCloud[20]가 있다.6. 한계 및 대응
기회주의적 TLS는 기회주의적 암호화 방식으로 작동하지만, 통신 시작 단계인 초기 핸드셰이크가 암호화되지 않은 평문으로 이루어진다는 본질적인 한계를 가진다. 이 때문에 네트워크 경로를 제어할 수 있는 공격자가 중간자 공격을 통해 통신 내용을 엿보거나 조작하기 쉽다. 대표적인 공격 기법으로 '''STRIPTLS'''가 있는데, 이는 서버가 TLS 암호화를 지원함에도 불구하고 지원하지 않는 것처럼 클라이언트를 속여 평문 통신을 유도하는 방식이다.[6][7][8] 이러한 공격은 사용자의 이메일 내용이나 비밀번호 같은 민감 정보가 그대로 노출될 위험을 초래하며, 실제로 일부 ISP가 사용자 통신에 이러한 기법을 사용한 사례도 보고되었다.[6][7][8]
이러한 취약점에 대응하기 위해 여러 방법이 시도되고 있다. SMTP 클라이언트 설정에서 TLS 사용을 강제하는 방법,[9] DNSSEC 기반의 DANE 기술을 이용해 서버의 TLS 지원 여부를 사전에 확인하는 방법(RFC 7672), 그리고 주요 이메일 서비스 제공업체들이 제안한 MTA-STS 프로토콜 등이 있다.[12] MTA-STS는 DNSSEC의 복잡성을 피하면서 인증 기관(CA)과 최초 사용 시 신뢰(TOFU) 방식을 활용한다.
하지만 이러한 대응책에도 불구하고, 기회주의적 TLS는 이메일이 여러 서버를 거쳐 전송되는 과정(홉) 사이의 보안만을 확보할 뿐, 이메일 내용 자체의 종단 간 기밀성이나 무결성을 완벽하게 보장하지는 못한다.[21][22] 메일 서버 운영자는 TLS 연결만을 강제할 수 없으며,[23] DNS 스푸핑과 같은 공격에는 여전히 취약할 수 있다.[25] 따라서 이메일의 완전한 보안을 위해서는 S/MIME과 같이 메시지 자체를 암호화하고 서명하는 별도의 보안 계층이 필요하다.[26][27]
6. 1. STRIPTLS 공격
기회주의적 TLS는 기회주의적 암호화 메커니즘의 일종이다. 하지만 초기 핸드셰이크 과정이 암호화되지 않은 평문으로 이루어지기 때문에, 네트워크 경로를 제어할 수 있는 공격자가 중간자 공격을 통해 서버가 보내는 메시지를 조작할 위험이 있다. 공격자는 서버가 TLS를 지원하지 않는 것처럼 보이게 만들어 클라이언트가 암호화되지 않은 평문 통신을 하도록 유도할 수 있는데, 이를 '''STRIPTLS 공격'''이라고 부른다. 이 공격이 성공하면, 많은 SMTP 클라이언트는 사용자의 이메일 내용이나 비밀번호 같은 민감한 정보를 평문으로 전송하게 되며, 사용자에게 별다른 경고 없이 이루어지는 경우가 많다. 특히, 메일 서버 간의 통신에서는 사용자에게 알림을 보내는 것이 현실적으로 어렵기 때문에 더욱 취약하다.실제로 2014년 9월, 태국의 두 ISP가 자사 고객들을 대상으로 STRIPTLS 공격과 유사한 방식으로 통신을 감청한 사실이 드러났다.[6][7] 같은 해 10월에는 미국의 통신사 AT&T의 자회사인 크리켓 와이어리스 역시 유사한 행위를 한 것이 밝혀졌다. 이 행위는 크리켓 와이어리스가 합병하기 전인 Aio Wireless 시절인 2013년 9월 초부터 시작된 것으로 알려졌다.[8][6]
STRIPTLS 공격의 예시는 다음과 같다. 아래는 태국의 대량 감시 기술에서 사용된 것으로 추정되는 공격 방식으로, 정상적인 통신(오른쪽)에서는 서버가 `STARTTLS` 명령어를 통해 TLS 지원을 알리지만, 공격 상황(왼쪽)에서는 이 명령어가 제거되어 클라이언트는 TLS 없이 평문 통신을 시작하게 된다.[10]
'''공격 상황 (STARTTLS 제거됨)'''
```
220 smtp.gmail.com ESMTP mail.redacted.com - gsmtp
ehlo a
250-smtp.gmail.com at your service, [REDACTED SERVICE]
250-SIZE 35882577
250-8BITMIME
# STARTTLS 명령어가 여기서 제거됨
250-ENHANCEDSTATUSCODES
250-PIPELINING
250 SMTPUTF8
```
'''정상 통신'''
```
220 smtp.gmail.com ESMTP - gsmtp
ehlo a
250-smtp.gmail.com at your service
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250 SMTPUTF8
```
STRIPTLS 공격을 막기 위해 SMTP 클라이언트 설정에서 보내는 연결에 대해 항상 TLS를 사용하도록 강제할 수 있다. 예를 들어, Exim 메시지 전송 에이전트는 `hosts_require_tls` 설정을 통해 이를 구현할 수 있다.[9] 하지만 모든 메일 서버가 TLS를 지원하는 것은 아니기 때문에, 모든 연결에 TLS를 강제하는 것은 현실적으로 어렵다.
이 문제를 해결하기 위한 기술적 접근 방법도 있다. DNSSEC의 일부인 DNS 기반 이름 엔터티 인증(DANE), 특히 SMTP를 위한 RFC 7672는 클라이언트 측에서 지원될 경우 해결책이 될 수 있다. DANE은 DNS의 TLSA 레코드를 통해 해당 서버가 보안 SMTP(TLS)를 지원한다는 사실을 광고하고, 클라이언트에게 TLS 연결을 요구하도록 알려 STRIPTLS 공격을 방지한다. 전자 프론티어 재단의 STARTTLS Everywhere 프로젝트도 비슷한 원리로 작동한다.
그러나 DNSSEC는 배포의 복잡성과 여러 비판[11]으로 인해 널리 사용되지 못했다. 이에 마이크로소프트, 구글, 야후 등 주요 이메일 서비스 제공업체들은 MTA-STS(SMTP MTA Strict Transport Security)라는 새로운 프로토콜을 제안했다.[12] MTA-STS는 DNSSEC 대신 기존의 인증 기관(CA) 시스템과 최초 사용 시 신뢰(TOFU, Trust on First Use) 방식을 사용하여 중간자 공격을 방지한다. TOFU 모델은 DNSSEC보다 덜 복잡하지만, 최초 연결 시의 보안 보장은 DNSSEC보다 약하다는 단점이 있다. MTA-STS는 또한 실패 보고 메커니즘과 보고 전용 모드를 도입하여 점진적인 도입과 규정 준수 감사를 용이하게 한다.
이메일 통신은 기본적으로 여러 서버를 거쳐 전달되는 방식[21]이기 때문에, TLS를 사용하더라도 각 구간(홉)의 보안만 확보될 뿐 종단 간 보안을 완벽하게 보장하기는 어렵다. 구체적인 한계는 다음과 같다.
- 메일 발신 측에서 TLS 사용을 강제할 방법이 없고, 모든 중계 서버가 TLS를 사용할 것이라는 보장이 없다.[22]
- 공개된 메일 서버는 TLS 연결만을 강제할 수 없으며[23], 평문으로 이루어지는 STARTTLS 협상 과정이 조작되면 이후 통신도 평문으로 이루어질 수 있다.[22] 실제로 2014년에는 ISP에 의한 STARTTLS 방해 사례도 보고되었다.[24]
- DNS 스푸핑 공격이 발생하면, 모든 구간에서 TLS 연결이 유지되더라도 중간자 공격이 성공할 수 있다.[25]
결론적으로 기회주의적 TLS만으로는 이메일의 완전성, 기밀성 확보, 발신자 인증 등을 완전히 실현하기 어렵다.[26] 이러한 보안 목표를 달성하기 위해서는 S/MIME과 같이 이메일 내용 자체를 암호화하는 상위 계층의 보안 기술이 필요하다.[27]
6. 2. 사례
기회주의적 TLS는 초기 핸드셰이크 과정이 암호화되지 않은 평문으로 이루어지기 때문에 중간자 공격에 취약하다. 공격자는 네트워크를 제어하여 서버 메시지를 조작함으로써 TLS 연결을 불가능하게 만들 수 있는데, 이를 '''STRIPTLS 공격'''이라고 한다. 이 공격이 성공하면 대부분의 SMTP 클라이언트는 사용자에게 별다른 알림 없이 이메일 내용이나 비밀번호 같은 민감 정보를 평문으로 전송하게 된다. 특히 메일 서버 간 통신에서는 사용자 알림 자체가 어렵다.실제로 이러한 공격 사례가 보고된 바 있다.
- 2014년 9월, 태국의 두 ISP가 자사 고객들을 대상으로 STRIPTLS 공격을 수행한 사실이 밝혀졌다.[6][7] 이는 국가 차원의 대량 감시 활동과 연관되었을 가능성이 제기된다.
- 2014년 10월에는 미국 통신 대기업 AT&T의 자회사인 Cricket Wireless 역시 고객들에게 동일한 공격을 가한 것으로 드러났다. 이 행위는 Cricket Wireless가 2013년 9월 인수한 Aio Wireless 시절부터 시작되어 합병 이후에도 지속된 것으로 확인되었다.[8][6] 기업이 고객의 통신 내용을 들여다보기 위해 보안 기능을 무력화시킨 사례로 볼 수 있다.
아래는 태국의 대량 감시 기술에서 사용된 것으로 추정되는 STRIPTLS 공격의 예시이다.[10] 공격자는 중간에서 STARTTLS 명령어를 제거하여 클라이언트와 서버 간의 암호화된 통신(TLS) 시작을 방해한다.
| 정상적인 통신 (TLS 사용 가능) | STRIPTLS 공격 (TLS 비활성화) |
|---|---|
이러한 STRIPTLS 공격은 이메일 통신의 보안을 심각하게 저해하며, 사용자의 민감 정보가 의도치 않게 노출될 위험을 높인다. 특히 통신 사업자나 정부 기관에 의한 감시 목적으로 악용될 수 있다는 점에서 문제가 크다.[24]
6. 3. 대응 방안
기회주의적 암호화의 일종인 기회주의적 TLS는 초기 연결 설정 과정(핸드셰이크)이 암호화되지 않은 평문으로 이루어진다는 약점을 가진다. 네트워크를 장악한 공격자는 이 과정에 개입하여 서버가 보내는 응답 메시지를 조작함으로써, 마치 해당 서버가 TLS를 지원하지 않는 것처럼 위장할 수 있다. 이를 '''STRIPTLS''' 공격이라고 부른다.[6][7] 이 공격이 성공하면, 대부분의 SMTP 클라이언트는 암호화되지 않은 상태로 이메일 내용이나 계정 비밀번호까지 전송하게 되며, 사용자에게 별다른 경고를 보내지 않는 경우가 많다. 특히 메일 서버 간의 통신에서는 사용자가 직접 개입하기 어려워 더욱 문제가 될 수 있다.[8]STRIPTLS 공격에 대응하기 위한 몇 가지 방법은 다음과 같다.
=== 클라이언트 측 설정 ===
이메일을 보내는 SMTP 클라이언트 측에서 TLS 사용을 의무화하도록 설정하는 것이 가장 직접적인 방법이다. 예를 들어, Exim과 같은 메시지 전송 에이전트는 "hosts_require_tls" 같은 설정을 통해 특정 서버로 메일을 보낼 때 반드시 TLS 연결을 사용하도록 강제할 수 있다.[9] 하지만 세상의 모든 메일 서버가 TLS를 지원하는 것은 아니므로, 무조건 TLS 사용을 강제하면 이메일 전송 실패를 유발할 수 있어 현실적으로 실용적이지 않다는 한계가 있다.
=== DANE (DNS-based Authentication of Named Entities) ===
DNSSEC 기술의 일부인 DANE은 DNS 정보를 활용하여 이 문제를 해결하려는 시도이다. RFC 7672 표준에 따라, 메일 서버 운영자는 TLSA라는 특수한 DNS 레코드를 공개하여 자신의 서버가 보안 SMTP (TLS 암호화 통신)를 지원한다는 사실을 명시적으로 알릴 수 있다. 이메일을 보내려는 클라이언트는 메일을 보내기 전에 해당 서버의 TLSA 레코드를 확인하고, 레코드가 존재하면 반드시 TLS 연결을 시도하게 된다. 이를 통해 중간에서 공격자가 TLS 지원 정보를 제거하는 STRIPTLS 공격을 무력화할 수 있다. 전자 프론티어 재단(EFF)의 'STARTTLS Everywhere' 프로젝트도 비슷한 접근 방식을 사용한다. 그러나 DANE은 기반 기술인 DNSSEC의 배포가 복잡하고 여러 비판[11]에 직면해 있어 아직 널리 채택되지는 못하고 있다.
=== MTA-STS (SMTP MTA Strict Transport Security) ===
구글, 마이크로소프트, 야후 등 주요 이메일 서비스 제공업체들은 DNSSEC의 복잡성을 피하면서도 보안성을 높이기 위해 MTA-STS라는 새로운 프로토콜을 제안했다.[12] MTA-STS는 DNSSEC 대신 기존의 인증 기관(CA) 시스템과 최초 사용 시 신뢰(TOFU, Trust On First Use) 모델을 결합하여 중간자 공격을 방지한다. 즉, 클라이언트는 처음 메일 서버에 접속했을 때의 TLS 설정을 기억해두고, 이후 접속 시 설정이 달라지면 경고하거나 접속을 차단하는 방식이다. TOFU 모델은 DNSSEC만큼 강력한 최초 사용 시점의 보안을 보장하지는 못하지만, 구현이 상대적으로 간단하다는 장점이 있다. 또한 MTA-STS는 TLS 연결 실패 시 보고서를 받아볼 수 있는 기능과, 실제 정책을 적용하기 전에 테스트해볼 수 있는 '보고 전용 모드'를 제공하여 점진적인 도입과 관리를 용이하게 한다.
=== 근본적인 한계 ===
위와 같은 대응 방안에도 불구하고, 기회주의적 TLS는 이메일 전송 경로상의 각 서버 구간(홉) 사이의 통신만을 암호화할 뿐, 이메일 메시지 자체의 무결성이나 기밀성을 종단 간(end-to-end)으로 보장하지는 못한다.[21][22] 메일 서버가 TLS 연결만을 강제할 수도 없고[23], 평문으로 이루어지는 STARTTLS 협상 과정이 공격자에 의해 변조되면 이후 통신 전체가 평문으로 이루어질 수 있다.[22] 또한 DNS 스푸핑 공격이 성공하면, 모든 구간에서 TLS 연결이 이루어진다 하더라도 공격자가 중간에서 내용을 엿보거나 위변조하는 중간자 공격이 여전히 가능하다.[25] 따라서 이메일 내용 자체를 안전하게 보호하고 발신자의 신원을 확실히 인증하기 위해서는, 기회주의적 TLS와 별개로 S/MIME이나 PGP와 같이 이메일 메시지 자체를 암호화하고 전자서명하는 상위 계층의 보안 기술을 함께 사용해야 한다.[26][27]
7. 대중적 인기
에드워드 스노든의 전 세계 대량 감시 스캔들 폭로 이후, 주요 이메일 제공업체들은 이메일 보안 강화를 위해 STARTTLS를 활성화하는 추세를 보였다.[13] 예를 들어, 페이스북은 STARTTLS를 도입하고 다른 업체들에게도 이를 권장했다. 그 결과, 2014년 2월 페이스북이 이메일 서비스를 중단하기 전까지 발신 이메일의 95%가 완벽한 전방향 보안과 엄격한 인증서 검증을 통해 암호화되었다고 보고했다.[14]
참조
[1]
웹사이트
tls Extension
https://ircv3.net/sp[...]
IRCv3 Working Group
2024-04-06
[2]
웹사이트
The Transport Layer Security (TLS) Protocol
http://tools.ietf.or[...]
RFC Editor
2009-10-08
[3]
웹사이트
SMTP Service Extension for Secure SMTP over Transport Layer Security
http://tools.ietf.or[...]
RFC Editor
2009-10-08
[4]
웹사이트
STARTTLS & EHLO
http://www.ietf.org/[...]
Internet Mail Consortium
2015-09-16
[5]
문서
Dovecot (software)
http://wiki2.dovecot[...]
[6]
뉴스
ISPs Removing Their Customers' Email Encryption
https://www.eff.org/[...]
2014-11-11
[7]
뉴스
Google, Yahoo SMTP email servers hit in Thailand
http://www.telecomas[...]
2014-09-12
[8]
뉴스
The FCC Must Prevent ISPs From Blocking Encryption
http://www.goldenfro[...]
2014-11-04
[9]
웹사이트
Exim Internet Mailer - The smtp transport
http://www.exim.org/[...]
[10]
간행물
Who's That Knocking at my door? Understanding Surveillance in Thailand
https://privacyinter[...]
2020-02-07
[11]
뉴스
Against DNSSEC
http://sockpuppet.or[...]
2016-03-18
[12]
웹사이트
SMTP MTA Strict Transport Security (MTA-STS)
https://tools.ietf.o[...]
2019-02-22
[13]
뉴스
Facebook's security chief on the Snowden effect, the Messenger app backlash and staying optimistic
https://www.washingt[...]
2014-11-02
[14]
웹사이트
Facebook: 95% of Notification Emails Encrypted Thanks to Providers' STARTTLS Deployment
http://allfacebook.c[...]
2014-08-19
[15]
웹사이트
The Transport Layer Security (TLS) Protocol
https://datatracker.[...]
RFC Editor
2008-08
[16]
웹사이트
SMTP Service Extension for Secure SMTP over Transport Layer Security
https://datatracker.[...]
RFC Editor
2002-02
[17]
웹사이트
STARTTLS & EHLO
https://mailarchive.[...]
Internet Mail Consortium
2009-01-26
[18]
문서
SMTP에서는, 인증은 필수가 아니다
[19]
웹사이트
More STARTTLS support!
http://securitynirva[...]
2011-10
[20]
웹사이트
Using Postbox with iCloud Accounts : Postbox Support
http://support.postb[...]
2011-11
[21]
문서
『マスタリングTCP/IP SSL/TLS編』、pp.408-409
[22]
문서
『マスタリングTCP/IP SSL/TLS編』、p.406
[23]
문서
『マスタリングTCP/IP SSL/TLS編』、p.400
[24]
웹사이트
ISPs Removing Their Customers' Email Encryption
https://www.eff.org/[...]
전자フロンティア재단
2014-11-11
[25]
문서
『マスタリングTCP/IP SSL/TLS編』、p.407
[26]
문서
『マスタリングTCP/IP SSL/TLS編』、p.409
[27]
문서
『マスタリングTCP/IP SSL/TLS編』、p.451
[28]
웹인용
tls Extension
https://ircv3.net/sp[...]
IRCv3 Working Group
2024-04-06
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com