假設決定在 Google 搜尋「最佳和牛 steak 醬汁」。您瀏覽了幾個網頁，然後在搜索結果的第二頁上，從 Chrome 瀏覽器收到這個通知：
出現了問題，這是肯定的。發生了什麼事？是否應該在沒有私密連接的情況下繼續訪問該頁面？
一位 IT 專家肯定會回答：
您遇到的錯誤可能是因為 SSL/TLS 握手失敗。
SSL？TLS？？這些縮寫您無疑聽過，但對於未受過訓練的心智來說，這些縮寫無疑會引起一種沉悶的困惑。在這篇文章中，我們將嘗試解釋什麼是 SSL/TLS，它是如何運作的，至少您將了解地址欄上那個鎖定圖標的意義。
TLS 的起源
TLS 代表傳輸層安全性，目前是最常見的網絡 PKI。它不僅用於加密互聯網瀏覽，還用於端到端連接（視頻通話、消息傳遞、遊戲等）。
到目前為止，我們期望互聯網上的幾乎所有連接都是加密的，如果某些東西被加密，我們會收到類似於圖 A 中所見的警報。但情況並非一直如此。如果回到 90 年代中期，互聯網上幾乎沒有任何東西是加密的。這可能是因為當時使用互聯網的人較少，或者因為當時並沒有信用卡信息四處流動。
TLS 的歷史始於 Netscape。1994 年，它開發了安全套接字層 1——現代 TLS 的祖父。技術上講，它位於 TCP 和 HTTP 之間，作為安全層。雖然版本 1 僅在內部使用且充滿了錯誤，但很快就修復了所有問題並發佈了 SSL 2。然後，Netscape 在 1995 年對其進行專利，以防止其他人進行專利，從而可以免費發佈。這在當時的專利實踐中是一個非常奇怪但慷慨的舉動。
1995 年，世界首次接觸到 Internet Explorer，一款使用名為 PCT（私有通信技術）的競爭技術的瀏覽器，該技術與 SSL 非常相似。但在任何競爭中——只有一個贏家。在 1996 年 11 月，SSL 3 發佈，這當然是對 SSL 2 的改進。隨後，互聯網工程任務組成立了傳輸層安全工作組，以決定互聯網加密的新標準。它隨後從 SSL 更名為 TLS（據我們所知，這是因為 Microsoft 不希望 Netscape 擁有該名稱的優先權）。該小組實際上花了三年時間才發佈 TLS 1。它與 SSL 3 非常相似，以至於人們開始稱其為 SSL 3.1。但隨著時間的推移，通過更新，安全性大幅提升；錯誤被消除，加密算法得到改進，協議得到更新等。
但，這一切實際上是如何運作的？
TLS 是一種 PKI 協議，存在於兩個實體之間。它們必須就某些事情達成一致，以識別彼此為可信的。這一識別過程稱為「握手」。
讓我們以 TLS 1.2 握手為例。
首先，載入任何網頁，然後根據您的瀏覽器，按下網頁地址文本框旁邊的鎖定圖標。您將看到證書信息，並在某些行之間找到如下字符串：
這被稱為加密套件。它是一種字符串表示形式的「握手」配方。
那麼，讓我們來看看這裡顯示的一些內容：
- 首先，我們有 ECDHE（橢圓曲線 Diffie–Hellman），這是一種密鑰協議，允許兩個擁有橢圓曲線公私鑰對的實體在不安全通道上建立共享秘密。通俗來說，這稱為密鑰交換；
- RSA 是我們的公鑰身份驗證機制（記住，我們需要公鑰才能進行任何 PKI）；
- AES256 指的是我們將要使用的加密算法（AES）及其密鑰大小（256）；
- 最後，SHA384 實際上是一個用於執行哈希函數的構建塊。
現在，關鍵是在僅幾條消息中交換所有數據。
當我們訪問新網頁時究竟發生了什麼？
在建立 TCP（傳輸控制協議）連接後，我們開始握手。與往常一樣，客戶端用戶請求來自服務器的數據——因此他發送了一條「客戶端你好」消息，其中包含一堆數據，包括：
- 該客戶端可以支持的最大 TLS 版本，以便雙方能夠「講同一種語言」；
- 用於防止重放攻擊的隨機數；
- 該客戶端支持的加密套件列表。
假設服務器是在線的，它會以「服務器你好」回應，包含它選擇與客戶端連接的加密套件和 TLS 版本 + 一個隨機數。如果服務器因版本不兼容而無法選擇套件或 TLS 版本——它會發送一個 TLS 警報，顯示握手失敗。此時，客戶端和服務器都知道通信協議。
請記住，服務器正在發送公鑰和包含 RSA 密鑰的證書。了解證書有過期日期是重要的。到文章結尾，您將明白為什麼。
此外，服務器還發送了一條服務器密鑰交換消息，其中包含 ECDHE 的參數和公值。這條交換消息還包含數字簽名（所有先前的消息都使用哈希函數進行摘要並使用服務器的私鑰簽名）。這個簽名至關重要，因為它提供了服務器身份的證明。
當服務器完成傳輸上述所有消息後，它會發送一條「服務器你好完成」消息。通俗來說，這是一條「我今天完成了，待會兒酒吧見」的消息。
另一方面，客戶端將查看證書並進行驗證。之後，它將使用證書驗證簽名（沒有證書就不能有簽名）。如果一切順利，客戶端將確認服務器的真實性並發送一條客戶端密鑰交換消息。這條消息不包含證書，但包含一個預主密鑰。然後將其與在「你好」消息中生成的隨機數結合，以產生主密鑰。該主密鑰將用於下一步的加密。
現在看起來可能非常複雜，但我們快完成了！
下一個階段涉及客戶端發送「變更加密規範」消息，這基本上意味著「我已經擁有所有內容，因此我可以開始加密——我將發送的下一條消息將使用參數和密鑰進行加密」。
之後，客戶端繼續發送「完成」消息，該消息包含到目前為止所有消息的摘要，並已進行加密。這有助於確保沒有人篡改消息；如果服務器無法解密該消息，它將離開「對話」。
服務器將以相同方式回應——發送變更加密規範和完成消息。
握手現在已完成，雙方可以交換 HTTP 請求/響應並加載數據。順便提一下，HTTP 和 HTTPS 之間的唯一區別是後者是安全的——這就是「S」的含義。
如您所見，破解這個系統是非常困難的。然而，這正是我們需要確保安全性。此外，數據傳輸的兩次往返幾乎沒有時間，這很好；沒有人希望 GitHub 加載一個半月。順便提一下，更先進的 TLS 1.3 僅需一次往返即可完成所有操作！
您的連接並不私密
當 TLS 出現問題時，您會看到我們在文章開頭演示的警告。通常，這些問題與證書及其過期日期有關。這就是為什麼如果您更改了設備的時間和日期設置，互聯網將拒絕工作。但是，如果日期和時間均正常——切勿訪問觸發此警告的網站，因為很可能在您和服務器之間，有人正在解析您的私人數據。
日本電話卡推介 / 韓國電話卡推介
一㩒即做：香港網速測試 SpeedTest HK
