기회주의적 TLS

Opportunistic TLS
「STARTTLS」는 여기서 리다이렉트 됩니다.인증국에 대해서는 [StartCom]ssl [ StartSSL ]를 참조해 주세요.

Opportunistic TLS(Transport Layer Security)는 플레인텍스트 통신 프로토콜의 확장을 말합니다.이 프로토콜은 암호화된 통신에 별도의 포트를 사용하는 대신 플레인텍스트 연결을 암호화된(TLS 또는 SSL) 연결로 업그레이드하는 방법을 제공합니다.일부 프로토콜은 이러한 목적으로 "STARTTLS"라는 명령을 사용합니다.이것은 기회주의적 암호화의 한 형태이며 주로 수동 모니터링에 대한 대응책으로 사용됩니다.

IMAP 및 POP3의 STARTTLS 명령어는 에서 정의되어 있습니다. RFC2595, RFC3207의 SMTP, RFC6120의 XMPP 및 RFC4642의 NNTP.IRC의 경우 IRCv3 작업 그룹은 STARTTLS 확장을 정의했습니다.FTP는 RFC4217에서 정의된 "AUTH TLS" 명령을 사용하고 LDAP는 RFC2830에서 프로토콜 확장 OID를 정의합니다.HTTP는 업그레이드헤더를 사용합니다.

계층화

TLS는 응용 프로그램에 의존하지 않습니다.RFC 5246에서는 다음과 같습니다.

TLS의 장점 중 하나는 애플리케이션 프로토콜에 의존하지 않는다는 것입니다.상위 레벨 프로토콜은 TLS 프로토콜 위에 투명하게 계층화할 수 있습니다.단, TLS 표준에서는 프로토콜이 TLS를 사용하여 보안을 추가하는 방법은 규정되어 있지 않습니다.TLS 핸드쉐이킹을 시작하는 방법과 교환되는 인증증명서를 해석하는 방법에 대한 결정은 [1]TLS 위에서 실행되는 프로토콜 설계자 및 구현자의 판단에 맡깁니다.

TLS 사용 방법을 지정하는 데 사용되는 스타일은 TLS의 여러 라이브러리 구현에서도 쉽게 지원되는 동일한 레이어 구분과 일치합니다.예를 들어, RFC 3207 SMTP 확장에서는 클라이언트와 서버가 [2]어떻게 안전한 세션을 시작할 수 있는지를 다음 대화 상자에 나타냅니다.

S:<>TCP포트 25&gt에 연결을 기다린다;C:<>connection&gt을 연다;S:220mail.example.orgESMTP 서비스 준비가 되어 C:EHLOclient.example.orgS:250-mail.example.org을 제공하는 따뜻한 포옹의 환영 S:250STARTTLSC:STARTTLSS:220Go 앞서 C:<>시작해 TLSnegotiation> 각각&S:<>협상한 TLSsession> 각각&S:.<>negotiation&gt의 결과 확인;C: EHLO client.example[3].org .

위의 마지막 EHLO 명령은 보안 채널을 통해 실행됩니다.인증은 SMTP 에서는 옵션입니다.따라서 생략된 서버 응답은 플레인텍스트 응답에는 없는 AUTH PLIN SMTP 확장을 안전하게 애드버타이즈 할 수 있습니다.

SSL 포트

기회주의적인 TLS의 사용 외에도 잘 알려진 프로토콜의 SSL 보안 버전에 대해 많은 TCP 포트가 정의되었습니다.이들은 안전한 통신을 확립한 후 암호화되지 않은 오래된 프로토콜과 동일한 통신 스트림을 제공합니다.개별 SSL 포트는 라운드 트립이 적고 암호화되지 않은 [4]형식으로 전송되는 메타데이터가 적다는 장점이 있습니다.예를 들어 다음과 같습니다.

프로토콜 목적 일반 포트 SSL 바리안트 SSL 포트
SMTP 이메일 보내기 25/587 SMTPS 465
POP3 전자 메일 검색 110 POP3S 995
IMAP 이메일 읽기 143 IMAPS 993
NNTP 뉴스 리더 119/433 NNT 563
LDAP 디렉토리 액세스 389 LDAPS 636
FTP 파일 전송 21 FTPS 990

적어도 이메일 관련 프로토콜의 경우 RFC 8314는 STARTTLS 대신 개별 SSL 포트를 선호합니다.

약점 및 완화점

Opportunistic TLS는 Opportunistic 암호화 메커니즘입니다.첫 번째 핸드쉐이크는 보통 텍스트로 이루어지기 때문에 네트워크를 제어하는 공격자는 중간자 공격을 통해 서버 메시지를 변경하여 TLS를 사용할 수 없는 것처럼 보이게 할 수 있습니다(STRIPTLS 공격이라고 불립니다).대부분의 SMTP 클라이언트는 보통 사용자에게 [citation needed]통지하지 않고 보통 텍스트로 전자 메일과 비밀번호를 보냅니다.특히 메일 서버 간에 많은 SMTP 연결이 이루어지며, 이 경우 사용자 통지가 실용적이지 않습니다.

2014년 9월, 태국에 있는 2개의 ISP가 자사 [5][6]고객에게 이러한 행위를 하고 있는 것이 판명되었습니다.2014년 10월, AT&T의 자회사인 Cricket Wireless가 고객에게 이러한 짓을 하고 있는 것이 밝혀졌습니다.이 행동은 2013년 9월에 Aio Wireless에 의해 시작되었으며, Aio Wireless는 나중에 크리켓과 합병하여 이러한 관행이 [7][5]지속되었습니다.

발신 접속에 TLS를 요구하도록 SMTP 클라이언트를 설정하는 것으로, STRIPTLS 공격을 블록 할 수 있습니다(예를 들면, Exim Message 전송 에이전트는, 디렉티브 「hosts_require_tls」[8]를 사용해 TLS 를 요구할 수 있습니다).그러나 모든 메일 서버가 TLS를 지원하는 것은 아니기 때문에 단순히 모든 연결에 TLS를 요구하는 것은 실용적이지 않습니다.

태국 대량 감시 [9]기술에 사용되는 유형의 STRIPTLS 공격의 예:

이 문제는 DNSSEC의 일부인 DNS 기반의 Authentication of Named Entities(DANE; 이름 있는 엔티티 인증)에 의해, 특히 SMTP 의 RFC 7672 에 의해서 해결되고 있습니다.DANE 에서는, TLSA 레코드를 개입시켜 시큐어 SMTP 의 서포트를 어드버타이즈 할 수 있습니다.이것에 의해, 접속하고 있는 클라이언트에 TLS가 필요하게 되어, FRIPTLS 공격이 방지됩니다.Electronic Frontier Foundation의 STARTTLS Everywhere 프로젝트도 비슷한 방식으로 작동합니다.그러나, 도입의 복잡성과 독특한[clarification needed] [10]비판으로 인해, DNSSEC는 낮은 채택률에 직면했고, SMTP MTA Strict Transport Security(MTA-STS)라고 불리는 새로운 프로토콜은 마이크로소프트, 구글, 야후를 포함한 주요 이메일 서비스 제공업체 그룹에 의해[11] 초안되었습니다.MTA-STS는 DNSSEC를 사용하여 DANE TLSA 레코드를 인증할 필요는 없지만 감청을 피하기 위해 CA(인증국) 시스템과 Trust-On-First-Use(TOF; 최초 사용 시 신뢰) 접근법에 의존합니다.TOUPU 모델은 복잡성을 줄여주지만 DNSSEC에서 제공하는 최초 사용 시 보증을 하지 않습니다.또한 MTA-STS는 장애 보고서 및 보고서 전용 모드를 도입하여 컴플라이언스를 위한 점진적인 롤아웃 및 감사를 가능하게 합니다.

인기

는 사실 에드워드 스노든이 세계 대량 감시 파문에서 만들어진 이후 인기 있는 이메일 제공 업체 STARTTLS.[12]페이스북은고, 다른 providers[ 모호한]을 격려하고 STARTTLS 이후까지 페이스북 2월 20에서 구글의 이메일 서비스 철회 보도했다 가능케 함으로써 그들의 이메일 보안 개선된 가지고 있다.14일 outb의 95%und e-메일은 Perfect Forward Secrecy와 엄격한 증명서 [13]검증으로 암호화되어 있습니다.

레퍼런스

  1. ^ Tim Dierks; Eric Rescorla (August 2008). "The Transport Layer Security (TLS) Protocol". RFC Editor. Retrieved 8 October 2009.
  2. ^ Paul Hoffman (February 2002). "SMTP Service Extension for Secure SMTP over Transport Layer Security". RFC Editor. Retrieved 8 October 2009.
  3. ^ 이 예의 마지막 행은 알기 쉽게 추가되어 있습니다.예를 들어, 다음에 의해 시작된 스레드 참조
  4. ^ Dovecot SSL 매뉴얼:http://wiki2.dovecot.org/SSL
  5. ^ a b Hoffman-Andrews, Jacob (11 November 2014). "ISPs Removing Their Customers' Email Encryption". Electronic Frontier Foundation. Retrieved 19 January 2019.
  6. ^ "Google, Yahoo SMTP email servers hit in Thailand". 12 September 2014. Retrieved 31 July 2015.
  7. ^ "The FCC Must Prevent ISPs From Blocking Encryption". 4 November 2014. Retrieved 31 July 2015.
  8. ^ "Exim Internet Mailer - The smtp transport". exim.org. hosts_require_tls - Exim will insist on using a TLS session when delivering to any host that matches this list.
  9. ^ "Who's That Knocking at my door? Understanding Surveillance in Thailand" (PDF). Privacy International: 21. January 2017. Retrieved 7 February 2020.
  10. ^ Thomas Ptacek (18 March 2016). "Against DNSSEC".
  11. ^ Ramakrishnan, Binu; Brotman, Alexander; Jones, Janet; Margolis, Daniel; Risher, Mark. "SMTP MTA Strict Transport Security (MTA-STS)". tools.ietf.org. Retrieved 22 February 2019.
  12. ^ Peterson, Andrea (12 August 2014). "Facebook's security chief on the Snowden effect, the Messenger app backlash and staying optimistic". The Washington Post. Retrieved 2 November 2014.
  13. ^ Cohen, David (19 August 2014). "Facebook: 95% of Notification Emails Encrypted Thanks to Providers' STARTTLS Deployment". allfacebook.com. Archived from the original on 22 September 2014.

외부 링크