SSL/TLS/StartTLS區別

先來段百度解釋：

    STARTTLS是對純文本通訊協議的擴展。它提供一種方式將純文本鏈接升級爲加密鏈接（TLS或SSL），而不是另外使用一個端口做加密通訊。

摘：https://www.fastmail.fm/help/technology_ssl_vs_tls_starttls.html

SSL vs TLS vs STARTTLS

SSL/TLS vs STARTTLS

There's often quite a bit of confusion about the different terms SSL vs TLS vs STARTTLS.

• SSL and TLS both provide a way to encrypt a communication channel between two computers (e.g. your computer and our server). TLS is the successor to SSL and the terms SSL and TLS are used interchangeably unless you're referring to a specific version of the protocol.
• STARTTLS is a way to take an existing insecure connection, and upgrade it to a secure connection using SSL/TLS. Note that despite having TLS in the name, STARTTLS doesn't mean you have to use TLS, you can use SSL.

 

SSL/TLS version numbers

Version numbering is inconsistent between SSL and TLS versions. When TLS took over SSL as the preferred protocol name, it began a new version number, and also began using sub-versions. So the ordering of protocols in terms of oldest to newest is: SSLv2, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2.

When you connect to an SSL/TLS encrypted port, or use STARTTLS to upgrade an existing connection, both sides will negotiate which protocol and which version to use based on what has been configured in the software and what each side supports.

Support for SSL/TLS is virtually universal these days, however which versions are supported is variable. Pretty much everything supports SSLv3 (except a few very old Palm Treo devices as we discovered). Most things support TLSv1.0. As at May 2012, support for TLSv1.1 and TLSv1.2 is more limited.

TLS vs STARTTLS naming problem

One significant complicating factor is that some email software incorrectly uses the term TLS when they should have used STARTTLS. Older versions of Thunderbird in particular used "TLS" to mean "enforce use of STARTTLS to upgrade the connection, and fail if STARTTLS is not supported" and "TLS, if available" to mean "use STARTTLS to upgrade the connection if the server advertises support for it, otherwise just use an insecure connection".

SSL/TLS vs plaintext/STARTTLS port numbers

The above is particularly problematic when combined with having to configure a port number for each protocol.

To add security to some existing protocols (eg IMAP, POP, etc), it was decided to just add SSL/TLS encryption as a layer underneath the existing protocol. However to distinguish that software should talk the SSL/TLS encrypted version of the protocol rather than the plaintext one, a different port number was used for each protocol. So you have:

• IMAP uses port 143, but SSL/TLS encrypted IMAP uses port 993
• POP uses port 110, but SSL/TLS encrypted POP uses port 995
• SMTP uses port 25, but SSL/TLS encrypted SMTP uses port 465

At some point, it was decided that having 2 ports for every protocol was wasteful, and instead you should have 1 port that starts off as plaintext, but the client can upgrade the connection to an SSL/TLS encrypted one. This is what STARTTLS was created to do.

There were a few problems with this though. There was already existing software that used the alternate port numbers with pure SSL/TLS connections. Client software can be very long lived, so you can't just disable the encrypted ports until all software has been upgraded.

Mechanisms were added to each protocol to tell clients that the plaintext protocol supported upgrading to SSL/TLS (e.g. STARTTLS), and that they should not attempt to login without doing the STARTTLS upgrade. This created two unfortunate situations:

1. Some software just ignored the "login disabled until upgraded" announcement and just tried to log in anyway, sending the user login name and password over plaintext. Even if the server then rejected the login, the details had already been sent over the Internet in plaintext.
2. Other software saw the "login disabled until upgraded" announcement, but then wouldn't upgrade the connection automatically, and thus reported login errors back to the user, which caused confusion about what was wrong.

Both of these problems resulted in significant compatibility issues with existing clients, and so most system administrators continued to just use plaintext connections on one port number, and encrypted connections on a separate port number.

This has now basically become the defacto standard that everyone uses. IMAP SSL/TLS encrypted over port 993 or POP SSL/TLS encrypted over port 995. Many sites are now disabling plain IMAP (port 143) and plain POP (port 110) altogether so people must use a SSL/TLS encrypted connection. By disabling ports 143 and 110, this removes completely STARTTLS as even an option for IMAP/POP connections.

SMTP STARTTLS as an exception

The one real exception to the above is SMTP. However that's for a different reason again. Most email software used SMTP on port 25 to submit messages to the email server for onward transmission to the destination. However SMTP was originally designed for transfer, not submission. So yet another port (587) was defined formessage submission. Although port 587 doesn't mandate requiring STARTTLS, the use of port 587 became popular around the same time as the realisation that SSL/TLS encryption of communications between clients and servers was an important security and privacy issue.

The result is that in most cases, systems that offer message submission over port 587 require clients to use STARTLS to upgrade the connection and also require a login to authenticate. There has been an added benefit to this approach as well. By moving users away from using port 25 for email submission, ISPs are now able to block outgoing port 25 connections from users' computers, which were a significant source of spam due to user computers that were infected with spam sending viruses.

Currently, things seem relatively randomly split between people using SMTP SSL/TLS encrypted over port 465, or people using SMTP with STARTTLS upgrading over port 587.

根據這篇文章的說明starttls最開始是以純文本協議來進行鏈接和協商的，做爲客戶端的一方會詢問服務器端是否支持ssl/tls加密，若是服務器端回答支持，那麼客戶端就開始以ssl/tls的方式發送數據，若是服務器端不支持，那麼還用原來的方式來發送數據。

不過遇到過這樣一個問題，採用普通的smtp發送郵件時是OK的，在增長了支持starttls的聲明後，卻沒法發送了，在用telnet命令測試服務器端是否支持starttls時，服務器端返回了 starttls ready，說明服務器端應該是支持starttls的，即使不支持，按理也應該可以支持普通的方式發送郵件纔對，可確實發送失敗了，目前還找不到緣由。

相應的郵件發送代碼以下：

http://fangyunfeng.iteye.com/blog/1847352

貼一個Gmail的例子：

Gmail支持smtp轉發和pop3接收.

POP3服務器地址： pop.gmail.com 端口：995 支持SSL

SMTP服務器地址： smtp.gmail.com 端口：465 或者 587 支持SSL（TSL）

 

465端口是SSL/TLS通信協議的 內容一開始就被保護起來了 是看不到原文的。
587端口是STARTTLS協議的 屬於TLS通信協議 只是他是在STARTTLS命令執行後纔對以後的原文進行保護的。

windows命令提示行下

>telnet smtp.gmail.com 587

220 mx.google.com ESMTP d1sm2045736tid.14
EHLO
250-mx.google.com at your service, [58.22.135.6]
250-SIZE 35651584
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 PIPELINING
AUTH LOGIN
530 5.7.0 Must issue a STARTTLS command first. d1sm2045736tid.14 （看到沒第2次命令，輸入AUTH他就提示「Must issue a STARTTLS command first.」）
STARTTLS
220 2.0.0 Ready to start TLS
.....這裏開始郵件內容的通信就被保護起來了
QUIT

via(感謝如下大牛的分享):

    http://en.wikipedia.org/wiki/STARTTLS

    http://fangyunfeng.iteye.com/blog/1847347

    http://blog.163.com/yang_jianli/blog/static/161990006201071913841594/