SSL 和 TLS 差異的功能影響
我知道 TLS 本質上是一個較新版本的 SSL，並且它通常支持將連接從不安全轉換為安全（通常通過 STARTTLS 命令）。
我不明白為什麼 TLS 對 IT 專業人員很重要，以及為什麼我會選擇其中一個。TLS 真的只是一個較新的版本嗎？如果是，它是一個兼容的協議嗎？
作為 IT 專業人員：我什麼時候使用哪個？我什麼時候不使用哪個？
簡短的回答：
SSL 是 TLS 的前身。SSL 是由 Netscape Communications 開發的專有協議，後來在 IETF 中標準化並更名為 TLS。簡而言之，版本按以下順序排列：SSLv2、SSLv3、TLSv1.0、TLSv1.1 和 TLSv1.2。
**與相對普遍的看法相反，這根本不是關於必須在具有 SSL 的不同埠上執行服務，並且能夠在與具有 TLS 的純文字變體相同的埠上執行服務。SSL 和 TLS 都可用於這兩種方法。**這是關於連接時的 SSL/TLS（有時稱為“隱式 SSL/TLS”）和在協議級別發出命令後的 SSL/TLS 之間的區別，通常
STARTTLS（有時稱為“顯式 SSL/TLS”） . 中的關鍵字STARTTLS是“START”，而不是 TLS。這是一條消息，在應用程序協議級別，表明需要切換到 SSL/TLS，如果在任何應用程序協議交換之前尚未啟動它。使用任何一種模式都應該是等效的，前提是客戶端配置為以一種或另一種方式期待 SSL/TLS，以免降級為純文字連接。
更長的答案：
SSL 與 TLS
據我所知，SSLv1 從未離開實驗室。SSLv2和SSLv3是 Netscape 開發的協議。SSLv2 一直被認為是不安全的，因為它容易受到降級攻擊。SSLv3 在內部
(3,0)用作其版本號（在ClientHello消息中）。TLS 是作為 IETF 內更開放的協議標準化的結果。（我想我在某個地方讀到過，也許是在 E. Rescorla 的書中，該名稱的選擇方式使所有參與者都對它同樣不滿意，以免偏袒某家公司：這是標準中相當普遍的做法body.) 那些對如何進行轉換感興趣的人可以閱讀SSL-Talk List FAQ；該文件有多個副本，但大多數連結（到
netscape.com）已過時。TLS 使用非常相似的消息（儘管可以協商一個通用版本，但差異足以使協議不兼容）。TLS 1.0、1.1和1.2
ClientHello消息使用,(3,1),來表示版本號(3,2)，(3,3)這清楚地表明了 SSL 的延續。在這個答案中有更多關於協議差異的細節。
我什麼時候用哪個？我什麼時候不使用哪個？
如果可能，請使用最高版本。實際上，作為服務提供商，這將要求您的使用者擁有支持這些版本的客戶端。像往常一樣，這始終是一項風險評估活動（如果合適，最好有商業案例支持）。話雖如此，無論如何都要切斷 SSLv2。
此外，請注意 SSL/TLS 提供的安全性不僅與您使用的版本有關，還與正確的配置有關：使用帶有強密碼套件的 SSLv3 肯定比帶有弱密碼套件的 TLSv1.0（或匿名/空加密）密碼套件。一些被認為太弱的密碼套件已被較新版本的 TLS 明確禁止。如果您想了解更多詳細資訊，您可能會對Java 7 SunJSSE 提供程序（及其腳註）中的表感興趣。
至少使用 TLS 1.1 會更好，但不幸的是，並非所有客戶端都支持它們（例如 Java 6）。當使用低於 1.1 的版本時，當然值得研究緩解 BEAST 漏洞。
我通常會向真正想要更多細節的人推薦Eric Rescorla 的書 - SSL 和 TLS：設計和建構安全系統，Addison-Wesley，2001 ISBN 0-201-61598-3 。
隱式與顯式 SSL/TLS
有一個神話說 TLS 允許您使用相同的埠，而 SSL 不能。這不是真的（我將不討論埠統一）。不幸的是，這個神話似乎已經傳播給使用者，因為某些應用程序（如 MS Outlook）有時會在其配置選項中提供 SSL 和 TLS 之間的選擇，而實際上它們意味著在隱式和顯式 SSL/TLS 之間進行選擇。（微軟有 SSL/TLS 專家，但他們似乎沒有參與 Outlook UI。）
我認為這種混亂發生的原因是因為
STARTTLS模式。有些人似乎已經將其理解為STARTTLS= TLS，但事實並非如此。中的關鍵字STARTTLS是“START”，而不是 TLS。為什麼不呼叫它STARTSSL，或者STARTSSLORTLS是因為這些擴展是在 IETF 中指定的，它只使用其規範中使用的名稱（假設 TLS 名稱最終將是唯一的名稱，我猜）。
- SSL 在與純文字服務相同的埠上：HTTPS 代理。
現在，大多數 HTTPS 伺服器都可以處理 TLS，但幾年前，大多數人使用 SSLv3 進行 HTTPS。HTTPS（嚴格來說，標準化為HTTP over TLS）通常在 TCP 連接上建立 SSL/TLS 連接，然後通過 SSL/TLS 層交換 HTTP 消息。在兩者之間使用 HTTP 代理時有一個例外。在這種情況下，客戶端以明文方式連接到 HTTP 代理（通常在埠 3128 上），然後發出
CONNECTHTTP 命令，如果響應成功，則通過發送一個ClientHello資訊。就瀏覽器和代理之間的連接而言，所有這些都發生在同一個埠上（顯然不在代理和目標伺服器之間：它甚至不是同一台機器）。這適用於 SSLv3。我們中的許多人在代理後面的情況下都會對至少不支持 TLS 1.0 的伺服器使用它。
- SSL 在與純文字服務相同的埠上：電子郵件。
這顯然不符合規範，但在實踐中，它通常有效。嚴格來說，規範討論的是在使用 STARTTLS 命令後切換到 TLS（而不是 SSL）。在實踐中，SSL 通常也可以工作（就像“HTTP over TLS”規範也包含使用 SSL 而不是 TLS）。你可以自己試試。假設您有一個支持 STARTTLS 的 SMTP 或 IMAP 伺服器，請使用 Thunderbird，進入首選項、高級選項、配置編輯器並關閉
security.enable_tls. 許多伺服器仍將接受連接，因為它們的實現將 SSL/TLS 層委託給 SSL/TLS 庫，該庫通常能夠以相同的方式處理 SSL 和 TLS，除非配置為不這樣做。正如OpenLDAP FAQ所說，“雖然該機制是為與 TLSv1 一起使用而設計的，但如果需要，大多數實現將回退到 SSLv3（和 SSLv2）。“。如果您不確定，請使用 Wireshark 之類的工具進行檢查。
- 不同埠上的 TLS。
許多客戶端可以（至少）將 TLS 1.0 用於安全變體位於不同埠的協議。顯然，有許多瀏覽器和 Web 伺服器支持 HTTPS 的 TLS 1.0（或更高版本）。同樣，SMTPS、IMAPS、POPS 和 LDAPS 也可以使用 TLS。它們不僅限於 SSL。
我什麼時候用哪個？我什麼時候不使用哪個？
在顯式和隱式 SSL/TLS 之間，這並不重要。重要的是您的客戶知道會發生什麼並進行了適當的配置。更重要的是，它應該被配置為在期待 SSL/TLS 連接時拒絕純文字連接，無論它是隱式的還是顯式的。
顯式和隱式 SSL/TLS 之間的主要區別在於配置設置的清晰度。
例如，對於 LDAP，如果客戶端是 Apache Httpd 伺服器（
mod_ldap不幸的是，它的文件也錯誤地標記了 SSL 和 TLS 之間的區別），您可以通過使用ldaps://URL（例如AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one）使用隱式 SSL/TLS 或使用顯式 SSL/ TLS 通過使用額外的參數（例如AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS）。一般來說，在 URL 方案（
https,ldaps, …）中指定安全協議時的風險可能比期望客戶端配置附加設置以啟用 SSL/TLS 時的風險要小一些，因為他們可能會忘記。這是有爭議的。一個與另一個的實現的正確性也可能存在問題（例如，我認為 Java LDAP 客戶端在使用時不支持主機名驗證ldaps://，何時應該支持，而ldap://+ StartTLS 支持）。值得懷疑的是，如果可能的話，為了與更多客戶端兼容，在伺服器支持時提供這兩種服務似乎沒有任何害處（您的伺服器將同時監聽兩個埠）。可以與任何一種模式一起使用的協議的許多伺服器實現都將支持這兩種模式。
客戶端有責任不讓自己被降級為純文字連接。作為伺服器管理員，您在技術上無能為力來防止降級攻擊（除了可能需要客戶端證書）。客戶端必須檢查 SSL/TLS 是否啟用，無論是在連接時還是在類似
STARTTLS命令之後。與瀏覽器不應該讓自己從https://to重定向一樣http://，支持協議的客戶端STARTTLS應該確保響應是肯定的，並且在繼續進行之前啟用了 SSL/TLS 連接。否則，活躍的 MITM 攻擊者可以輕鬆降級任一連接。例如，舊版本的 Thunderbird 對此有一個不好的選項，稱為“使用 TLS，如果可用”，這實質上暗示如果 MITM 攻擊者能夠更改伺服器消息使其不宣傳對 STARTTLS 的支持，客戶端會默默地讓自己降級為純文字連接。（這個不安全的選項在 Thunderbird 中不再可用。）