修復internet用戶和站點所有者的SSL/TLS握手失敗錯誤
現在是發表另一篇技術文章的時候了，今天我們將討論SSL/TLS握手失敗錯誤及其修復方法。與許多SSL錯誤消息一樣，這可以從客戶端和服務器端觸發，因此有時可以由普通互聯網用戶修復，而其他時候則表明網站存在配置問題。
不管它的起源如何，這都可能是一個令人沮喪的SSL錯誤，因爲它阻止您與試圖訪問的網站建立安全連接。
我們將瞭解SSL/TLS握手是什麼，然後我們將介紹SSL/TLS握手失敗錯誤的原因以及您可以做些什麼來修復它。
讓我們好好想想。
什麼是SSL/TLS握手？
在每個HTTPS連接開始時，客戶端（互聯網用戶的web瀏覽器）和服務器（託管網站）必須經過一系列檢查，以相互驗證並確定加密連接的參數。
TLS握手完成三件事：
將服務器驗證爲非對稱公鑰/私鑰對的合法所有者
確定將用於連接的TLS版本和密碼套件
交換將用於通信的對稱會話密鑰
如果您簡化PKI（作爲整個SSL/TLS生態系統的基礎設施），它實際上是關於安全密鑰交換的。在HTTPS連接期間，通信實際上是通過生成客戶端的對稱會話密鑰（通常是256位AES密鑰）完成的。當生成對稱密鑰時，雙方都會得到一個副本，並可以使用它來加密和解密。
雖然256位加密仍然足夠健壯，但真正的安全性是在入口，一個更大、更強的私鑰（通常是2048位RSA密鑰）有助於處理連接的身份驗證部分。身份驗證很重要，因爲客戶端希望確保它與正確的參與方連接。這就是握手的本質，它是一組檢查，在那裏客戶機和服務器相互驗證，確定HTTPS連接的參數（將使用什麼密碼套件），然後客戶機加密會話密鑰的副本，並將其發送到服務器以在連接期間使用。
從歷史上看，握手給連接增加了一點延遲，這就是爲什麼會有人聲稱HTTPS會減慢你的網站速度。不過，TLS協議的最新版本已經解決了這種延遲問題，所以現在這幾乎完全不正確，尤其是在HTTP/2和HTTP/3中。
目前，有兩種不同版本的TLS握手正在使用中。TLS 1.2使用握手，在客戶機和服務器之間進行多次往返。
我們不會一步一步地進行，但實際上，客戶機和服務器相互ping，提供SSL/TLS證書，客戶機對其進行身份驗證，他們交換一個受支持的密碼套件列表並就其中一個達成一致，然後進行密鑰交換。
TLS 1.3將TLS握手改進爲一次往返。
很明顯，這減少了連接啓動所需的時間——我們在這裏討論的是毫秒，所以可能不太明顯——並使一切都更加高效。TLS 1.3還允許0-RTT恢復，這將進一步簡化與啓用TLS 1.3的網站的後續連接。
但是，考慮到TLS握手中移動部件的數量，如果網站或設備配置錯誤，可能會出現很多問題。現在我們來討論一下TLS握手會出現什麼問題，以及需要做些什麼來修復它。
仔細看一下SSL/TLS握手
帕特里克·諾赫的所有加密技術
當你通過HTTPS連接到一個網站時，引擎蓋下面發生了很多事情。首先，每個人都需要…握手？！
SSL/TLS握手失敗錯誤概述
爲了使本文更易於理解，我們將介紹SSL/TLS握手失敗錯誤的所有可能原因以及誰可以修復這些錯誤，然後稍後我們將爲每個問題提供一個專門的部分，我們將介紹如何修復它們。
| CAUSE | DESCRIPTION | FIX |
| Incorrect System Time | Client device has the incorrect time & date | Client |
| Browser Error | A browser configuration is causing the error | Client |
| Man-in-the-Middle | A third party is intercepting/manipulating connection | Client |
| Protocol Mismatch | Protocol used by client is not supported by server | Server |
| Cipher Suite Mismatch | Cipher Suite used by client is not supported by server | Server |
| Incorrect Certificate |
|
Server |
| SNI-Enabled Server | Client can’t communicate with SNI-enabled server | Server |
現在讓我們深入討論解決這些問題和可以做的事情，然後我們將完成一些您絕對不應該從客戶端嘗試解決這個錯誤的事情。
SSL/TLS握手失敗-客戶端錯誤
當握手失敗時，通常是網站/服務器及其SSL/TLS配置的問題。
實際上，現在只是TLS配置，因爲對SSL 3.0的支持幾乎完全被否決了。
但是，在一些上下文中，客戶端錯誤可能導致SSL/TLS握手失敗錯誤。其中很多看起來都很簡單，比如確保系統時間正確，瀏覽器更新。
但是，正如我們所討論的，在TLS握手時有很多活動部件，有時甚至是最輕微的打嗝都會導致整個事情變得一團糟。
所以，讓我們來看看一些客戶端修復。
系統時間不正確
我真的不知道爲什麼有人會把他們的系統時鐘從通用時間選項中去掉，但很顯然這是真的。也許你想像精神病患者一樣遵守自己的個人時鐘，或者設置只是意外改變——這不關我的事，真的——但如果你的系統時間不對，可能會導致TLS握手出現問題。
這主要是因爲SSL/TLS證書的壽命有限，所以時間很重要。事實上，在一些相當引人注目的證書過期案例中，比如Oculus Rift虛擬現實系統，互聯網用戶甚至故意將其系統時間設置回到期前的某個日期，以便他們仍然可以連接。
顯然，不要這樣做。如果您仍然收到SSL/TLS握手失敗錯誤，並且您的系統時間正確，則該問題是由其他地方引起的。
瀏覽器錯誤
這不像是一個瀏覽器錯誤，這實際上是你的瀏覽器犯了一個錯誤。有時你的瀏覽器可能會配置錯誤，或者插件可能會導致工作方式有點不同，從而導致連接到其他合法網站的問題。雖然診斷當前瀏覽器上需要調整的內容可能有點困難，但將其縮小到文本瀏覽器錯誤是非常簡單的：只需嘗試另一個瀏覽器。
如果你使用的是Google Chrome，可以切換到蘋果Safari或微軟Edge等操作系統的原生瀏覽器，如果你有，也可以使用Mozilla Firefox（我的首選）。
只要把它打開，然後試着連接到站點。如果您得到相同的SSL/TLS握手失敗錯誤，您知道它不是瀏覽器。但是如果你能連接，現在你知道你的插件或設置有問題了。
解決這個問題的最快方法就是將瀏覽器重置爲默認設置並禁用所有插件。在那裏，你可以根據自己的需要配置瀏覽器，在你調整的時候測試你與相關站點的連接。這可能需要一點時間，但如果您的瀏覽器配置錯誤或出錯，這確實是解決問題的唯一方法。
中間人
中間人（MITM）通常被描述爲企圖竊取信息或造成傷害的邪惡黑客。事實上並不總是這樣。許多程序和設備爲了檢查或其他目的（如負載平衡）而攔截通信量，然後將其發送到應用服務器。這也構成了MITM。
不幸的是，有時這些設備的問題會導致TLS握手失敗。它可能類似於網絡防火牆阻止連接，也可能是服務器端網絡上的邊緣設備上的配置，因此此問題實際上可以是客戶端修復，也可以是服務器端修復，具體取決於場景。
這裏的事情，如果這個問題是客戶端，你可以冒險暴露自己，如果你與你的防病毒或VPN設置抖動。一般來說，應該有一種方法可以列出白名單，或者爲有問題的站點創建一個異常。但千萬不要放下防火牆或殺毒軟件，只需連接到一個網站。如果問題是服務器端的，則很可能是邊緣設備上的配置問題。最近，Ross Thomas告訴我他曾經處理過一個設備，這個設備攔截流量並附加一個小數據字符串以表明它通過了檢查。這導致數據無法通過校驗和散列，還可能干擾身份驗證。
同樣，對於我來說，有太多的可能來源來縮小到一個單一的修復，但是如果你有一個設備檢查或攔截流量，從那裏開始。
SSL/TLS握手失敗：服務器端錯誤
大多數時候，SSL/TLS握手失敗是服務器端問題的結果。其中有些很容易修復，有些更復雜，有些根本不值得修復。
讓我們看看。
協議不匹配
這實際上是一個在客戶端和服務器端都可能發生的錯誤，根據上下文的不同，它實際上可能不值得修復。在支持協議和密碼方面，最重要的一點是：永遠向前，永遠不要向後。
TLS 1.2十年前問世，但仍有一小部分網站不支持它。今年夏天早些時候，IETF最終將TLS 1.3發佈爲RFC 8446。建議各網站在早期方便時增加對TLS 1.3的支持。
另一方面，PCI DSS要求最近強制要求所有收集支付卡信息的網站最終支持SSL 3.0和TLS 1.0。谷歌、火狐、蘋果和微軟四大瀏覽器製造商聯合宣佈，到2020年，TLS 1.1將被棄用。
如果由於協議不匹配而導致SSL/TLS握手失敗錯誤，則意味着客戶端和服務器對同一TLS版本沒有相互支持。下面是一個例子：
| CLIENT | SERVER |
| Supports TLS 1.0, TLS 1.1 | Supports TLS 1.2 |
在這個場景中，沒有相互支持的TLS協議，服務器可能不支持向後版本控制。服務器不應該修復這個問題。在此示例中，客戶端應升級其瀏覽器，或者在瀏覽器爲當前版本的情況下，將其配置爲支持最新的TLS版本。
此時，您應該使用TLS 1.2或tls1.3，如果沒有，請添加對它們的支持。但請記住，永遠不要倒退。
密碼套件不匹配
這與協議不匹配非常相似——只是更精細一些。SSL/TLS不僅僅是一個處理所有事情的算法（儘管ECC很接近），它實際上是一個提供不同功能並與SSL/TLS協同工作的算法集合。
SSL/TLS就像Megazord，密碼套件就像Power Rangers。
什麼？你試圖使一組算法聽起來更有趣。
總之，雖然TLS 1.3使用的密碼套件已經過改進，但傳統的密碼套件有處理以下問題的算法：
非對稱公鑰加密
對稱會話密鑰加密
密鑰生成
簽名哈希
不同的行業和政府機構有不同的加密標準，建議使用不同的密碼套件。一般來說，這裏有很多重疊，而且大多數網站都支持少數密碼套件，這樣客戶機就有幾個選項，並且通常能夠找到一個雙方都滿意的密碼。顯然，如果一個站點只支持一個密碼套件，那麼成功協商的機率將大大降低。
如果執行SSL橋接（邊緣設備接收和解密HTTPS通信量，然後對其進行重新加密，以便將其發送到應用程序服務器），則在網絡中經常會發生這種情況。如果邊緣設備和應用程序服務器不共享相互支持的密碼套件，將導致錯誤。
與協議版本非常相似，您應該只使用密碼套件，而不是向後移動。請記住，當一個協議版本或密碼套件被棄用時，並不是因爲這個行業正試圖變得困難，而是因爲已經發現或迫在眉睫的漏洞。所以，向後走只會降低你的連接的安全性。
SSL/TLS證書不正確
有很多不同的東西可以使瀏覽器將SSL/TLS證書視爲不正確，並阻止握手成功完成。我們將在下一小節中逐一討論。值得注意的是，有時這些問題會在客戶端變成不同的錯誤，而不是SSL/TLS握手失敗消息。一般來說，網站上沒有提供安全連接的東西。但在技術層面上，錯誤是由於握手失敗而產生的。
| ISSUE | DESCRIPTION |
| Host Name Mismatch | The CN in the certificate does not match the host name |
| Incorrect Certificate Chain | The certificate chain is missing intermediates |
| Expired/Revoked Certificate | The server presented an expired, revoked or untrusted certificate |
| Self-Signed Replacements | (Internal Networks) Certificate replacements confused path |
主機名不正確
這曾經是WWW和非WWW版本的網站的一個問題，但證書頒發機構社區通常會減少這一問題，允許將一個站點免費列爲SAN。此問題通常可以通過重新頒發證書或有時使用通配符證書來解決。
證書鏈不正確
幾個月前，我們深入研究了證書鏈、根證書和中間證書，但這裏是快速版本。SSL/TLS和PKI中的信任模型通常依賴於精心管理的根程序，這些根程序是可信CA根證書的集合，它們實際上存在於計算機系統上。
| ROOT PROGRAM | USED BY |
| Mozilla | Firefox Desktop and Mobile |
| Android OS | |
| Apple | iOS, macOS |
| Microsoft | Windows |
這些CA根是非常寶貴的，以至於證書頒發機構沒有直接從中發出風險，而是將中間根旋轉起來，並與這些中間根簽署SSL/TLS leaf（最終用戶）證書。這就是鎖鏈開始進入的地方。根CA證書用於對中間根進行數字簽名，這些中間根用於對其他中間根或最終用戶的leaf SSL/TLS證書進行簽名。
當瀏覽器收到SSL/TLS證書時，它要做的檢查其真實性的一件事就是跟蹤簽名。它查看SSL/TLS證書上的數字簽名，然後返回到簽名它的中間根。然後，它查看中間層的數字簽名，並跟隨它返回到簽署中間層的證書。以此類推，直到最終到達其信任存儲區中的一個根CA證書。
如果它做不到這一點，證書鏈通常是不完整的，這意味着瀏覽器找不到中間層之一，並且SSL/TLS握手失敗。要解決這個問題，您需要找到並安裝丟失的中間證書。根據您購買證書的CA，它應該在其網站上提供其中間產物。
過期/吊銷的證書
雖然在當前的SSL/TLS生態系統中，撤銷操作還有很多需要改進的地方，但在某些上下文中，瀏覽器將看到證書已被撤銷，並且在此基礎上握手失敗。更常見的情況是由於證書過期。
RELATED: This is what happens when your SSL/TLS certificate expires
SSL/TLS證書過期有兩個原因：
確保驗證信息的準確性
以更快的速度擴展協議和密碼更新
現在，SSL/TLS證書的最大有效期是兩年（27個月，因爲CAs將允許您從以前的證書中攜帶最多3個月）。最終，可能會縮短到六個月。這意味着您需要定期交換證書。如果忘記了，這可能就是SSL/TLS握手失敗的原因。只要獲得一個有效的證書，並安裝它-這應該可以解決你的問題。
自簽名替換
在公共internet上，如果客戶端沒有在其根存儲中手動安裝您的私有根，則自簽名證書將100%返回錯誤。但是，在內部網絡上，自簽名證書相當常見。如果你把它們換得足夠多，可能會導致問題。
大多數瀏覽器都會緩存證書，這樣在返回網站時，握手速度會更快，但是如果您定期生成新證書，不斷地將所有新生成的證書添加到本地數據庫將導致混亂，最終瀏覽器將難以構建路徑並崩潰。
在過去，Firefox一直在努力解決這個問題，以至於7-8個證書的重新頒發將導致顯著的延遲，而10個或更多證書可能導致握手需要30秒以上。
啓用SNI的服務器
這更多的是設備之間存在的內部問題，但有時在未啓用SNI時與服務器名稱指示服務器通信的客戶端可能是SSL/TLS握手失敗的原因。
首先要做的是確定所討論的服務器的主機名和端口號，並確保它啓用了SNI，並且它可以傳遞所需的所有信息。再說一次，這通常不是一個公衆面臨的問題，但它可能是不時的內部原因。
什麼都不動-不要獎勵糟糕的SSL/TLS實現
很多時候，網站所有者不想做任何改變，直到它產生了一個他們不能忽視的問題。雖然有一些針對SSL/TLS握手失敗錯誤的客戶端修復，但通常是服務器端的。
這意味着作爲一個普通的互聯網用戶，你的選擇是有限的。最好的辦法是通知網站所有者問題並等待他們解決。如果他們不這樣做，最好停止使用網站。有些事情你絕對不應該去訪問網站：
不要放棄防火牆，你通常可以列出一個網站，但不要放棄防火牆。永遠。
如果可能的話，不要再次禁用你的防病毒軟件，但是要保持更新和開啓。
不要通過HTTP連接或單擊間隙警告
如果網站不能提供安全的瀏覽體驗，你不應該訪問它。