Opportunistic TLS(편의적 TLS)

[운영자]

출처: https://en.wikipedia.org/wiki/Opportunistic_TLS

"StartTLS" 관련해서는 여기를 참고 하세요: 링크

Opportunistic TLS:

1) Opportunistic 암호화란 이메일 서버에 존재하는 디지털 인증서를 인증하지 못한경우에도 인증된 것으로 추정한 채로 전송하나 이 트래픽 암호화는 그나마 아무것도 하지 않는 것보다는 낫다(인용:http://www.itworld.co.kr/news/98467)

2) 문제는 스타트TLS가 가장 기본적인 암호화 통신 기능을 제공하고 있어 누군가 이메일 훔쳐보기를 시도하면 손쉽게 이러한 기능을 무력화시킬 수 있다는 점이다. 스타트TLS는 한번 암호화 통신을 시도했다가 실패하면 다시 평문 형태로 통신을 시도한다. 이 같은 방식을 두고 '기회주의적인 암호화(opportunistic encryption)'라고 부른다.(인용:http://www.zdnet.co.kr/news/news_view.asp?artice_id=20160322094539&type=det&re=)

Opportunistic TLS는 평문 통신 프로토콜의 확장을 의미한다, 이는 평문으로 보내는 것외에 평문을 암호화(TLS 또는 SSL)하여 별도의 포트를 사용하여 통신을 할 수 있는 방법을 제공한다. 몇몇 프로토콜은 평문을 암호화하기 위해 "STARTTLS"라는 명령을 사용한다. 이것은 주로 수동 모니터링을 위한 대책으로 마련되었다.

IMAP 및 POP3에 대한 STARTTLS 명령은 RFC 2595에 정의 되어 있다. 그리고 SMTP에 대한 STARTTLS는 RFC 3207에 정의 되어 있으여,  XMPP는 RFC 6120, NNTP는 RFC 4642. IRC InspIRCd wiki에 정의 되어 있다. FTP는 "AUTH TLS"명령을 사용하는데 RFC 4217 에 정의되어 있으며, LDAP은  RFC 2830에 확장되어 OID프로토콜로 정의 되어있다.

목차
1 Layering(레이어링)
2 SSL ports(SSL 포트)
3 Weaknesses and mitigations(약점 및 방안)
4 Popularity(인기) 4.1 STARTTLS을 제공하는 것들

5 참고
6 참고 링크

Layering(레이어링)

TLS은 어플리케이션에 중립적이다; RFC 5246 인용:
TLS의 이점 중 하나는 어플리케이션 프로토콜에 독립적으로 적용할 수 있다는 점이다. 상위 레벨의 프로토콜은 깔끔하게 TLS프로토콜 위에 올라 갈 수 있다(2,3,4 계층의 프로토콜은 TLS프로토콜 위에 얹힐 수 없음). The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS.[1]
The style used to specify how to use TLS matches the same layer distinction that is also conveniently supported by several library implementations of TLS. E.g., the RFC 3207 SMTP extension illustrates with the following dialog how a client and server can start a secure session:[2]
  S: <waits for connection on TCP port 25>
  C: <opens connection>
  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: <starts TLS negotiation>
  C & S: <negotiate a TLS session>
  C & S: <check result of negotiation>
  C: EHLO client.example.org[3]
  . . .

The last EHLO command above is issued over a secure channel. Note that authentication is optional in SMTP, and the omitted server reply may now safely advertise an AUTH PLAIN SMTP extension, which is not present in the plain-text reply.

SSL ports[edit]

Before opportunistic TLS was well established, a number of TCP ports were defined for SSL-secured versions of well-known servers. These establish secure communications and then present a communication stream identical to the old un-encrypted protocol. These are no longer recommended, since opportunistic TLS makes more efficient use of scarce port numbers and allows simpler device configuration.[citation needed] On the other hand, SSL ports have the advantage of fewer round-trips; also less meta-data is transmitted in unencrypted form.[4] Some examples include:

Protocol

Purpose

Normal port

SSL variant

SSL port

SMTP Send email 25/587 SMTPS 465 (legacy)[5]
POP3 Retrieve email 110 POP3S 995
IMAP Read email 143 IMAPS 993
NNTP News reader 119/433 NNTPS 563
LDAP Directory Access 389 LDAPS 636
FTP File transfer 21 FTPS 990

Weaknesses and mitigations[edit]

Opportunistic TLS is an opportunistic encryption mechanism. Because the initial handshake takes place in plain text, an attacker in control of the network can modify the server messages via a man-in-the-middle attack to make it appear that TLS is unavailable (called a STRIPTLS attack). Most SMTP clients will then send the email and possibly passwords in plain text, often with no notification to the user. In particular, many SMTP connections occur between mail servers, where user notification is not practical.

In September 2014, two ISPs in Thailand were found to be doing this to their own customers.[6][7] In October 2014 Cricket Wireless, then a subsidiary of VPN provider Golden Frog was found to be doing this using Cisco[8] devices on their network in an attempt to inspect emails and block spam.[9][10]

STRIPTLS attacks can be blocked by configuring SMTP clients to require TLS for outgoing connections (for example, the Exim Message transfer agent can require TLS via the directive "hosts_require_tls" [11]). However, since not every mail server supports TLS, it is not practical to simply require TLS for all connections.

This problem is addressed by DNS-based Authentication of Named Entities (DANE), a part of DNSSEC, and in particular by RFC 7672 for SMTP. DANE allows to advertise support for secure SMTP via a TLSA record. This tells connecting clients they should require TLS, thus preventing STRIPTLS attacks. The STARTTLS Everywhere project from the Electronic Frontier Foundation works in a similar way.

Popularity[edit]

Following the revelations made by Edward Snowden in light of the global mass surveillance scandal, popular email providers have bettered their email security by enabling STARTTLS.[12] Facebook reported that after enabling STARTTLS and encouraging other providers to do the same, 95% of Facebook's outbound email is encrypted with both Perfect Forward Secrecy and strict certificate validation.[13]

Mainstream providers that employ STARTTLS[edit]
Amazon.com[14]
Comcast.net[15]
Dropbox.com[14]
Facebook.com[14]
Google.com[14] (Gmail)
Microsoft.com[14] (Outlook)
Sonic.net[14]
Spideroak.com[14]
Yahoo.com[14]