SM2演算法第十一篇：掃盲HTTPS和SSL/TLS協議
作者：程式設計隨想
本系列共有三節：
掃盲HTTPS和SSL/TLS協議[0]：引子（略了）
掃盲HTTPS和SSL/TLS協議[1]：背景知識、協議的需求、設計的難點
掃盲HTTPS和SSL/TLS協議[2]：可靠祕鑰交換的原理
----------------------------------------------------分割線--------------------------------------------------------
掃盲HTTPS和SSL/TLS協議[1]
背景知識、協議的需求、設計的難點
★相關背景知識
要說清楚 HTTPS 協議的實現原理，至少需要如下幾個背景知識。
1. 大致瞭解幾個基本術語（HTTPS、SSL、TLS）的含義
2. 大致瞭解 HTTP 和 TCP 的關係（尤其是“短連線”VS“長連線”）
3. 大致瞭解加密演算法的概念（尤其是“對稱加密與非對稱加密”的區別）
4. 大致瞭解 CA 證書的用途
考慮到很多技術菜鳥可能不瞭解上述背景，俺先用最簡短的文字描述一下。如果你自認為不是菜鳥，請略過本章節，直接去看“HTTPS 協議的需求”。
◇先澄清幾個術語——HTTPS、SSL、TLS
1. “HTTP”是幹嘛用滴？
首先，HTTP 是一個網路協議，是專門用來幫你傳輸 Web 內容滴。關於這個協議，就算你不瞭解，至少也聽說過吧？比如你訪問俺的部落格的主頁，瀏覽器位址列會出現如下的網址
http://program-think.blogspot.com/
俺加了粗體的部分就是指 HTTP 協議。大部分網站都是通過 HTTP 協議來傳輸 Web 頁面、以及 Web 頁面上包含的各種東東（圖片、CSS 樣式、JS ）。
2. “SSL/TLS”是幹嘛用滴？
SSL 是洋文“Secure Sockets Layer”的縮寫，中文叫做“安全套接層”。它是在上世紀90年代中期，由網景公司設計的。（順便插一句，網景公司不光發明了 SSL，還發明瞭很多 Web 的基礎設施——比如CSS 樣式表和JS指令碼） 。
為啥要發明 SSL 這個協議捏？因為原先網際網路上使用的 HTTP 協議是明文的，存在很多缺點——比如傳輸內容會被偷窺（嗅探）和篡改。發明 SSL 協議，就是為了解決這些。
到了1999年，SSL 因為應用廣泛，已經成為網際網路上的事實標準。IETF 就在那年把 SSL 標準化。標準化之後的名稱改為 TLS（是“Transport Layer Security”的縮寫），中文叫做“傳輸層安全協議”。
很多相關的文章都把這兩者並列稱呼（SSL/TLS），因為這兩者可以視作同一個東西的不同階段。
3. “HTTPS”是啥意思？
解釋完 HTTP 和 SSL/TLS，現在就可以來解釋 HTTPS 啦。咱們通常所說的 HTTPS 協議，說白了就是“HTTP 協議”和“SSL/TLS 協議”的組合。你可以把 HTTPS 大致理解為——“HTTP over SSL”或“HTTP over TLS”（反正 SSL 和 TLS 差不多）。
◇再來說說 HTTP 協議的特點
作為背景知識介紹，還需要再稍微談一下 HTTP 協議本身的特點。HTTP 本身有很多特點，考慮到篇幅有限，俺只談那些和 HTTPS 相關的
1. HTTP 的版本和歷史
如今咱們用的 HTTP 協議，版本號是 1.1（也就是 HTTP 1.1）。這個 1.1 版本是1995年底開始起草的（技術文件是 RFC2068），並在1999年正式釋出（技術文件是 RFC2616）。
在 1.1 之前，還有曾經出現過兩個版本“0.9 和 1.0”，其中的 HTTP 0.9 【沒有】被廣泛使用，而 HTTP 1.0 被廣泛使用過。
另外，據說明年（2015）IETF 就要釋出 HTTP 2.0 的標準了。俺拭目以待。
2. HTTP 和 TCP 之間的關係
簡單地說，TCP 協議是 HTTP 協議的基石——HTTP 協議需要依靠 TCP 協議來傳輸資料。
在網路分層模型中，TCP 被稱為“傳輸層協議”，而 HTTP 被稱為“應用層協議”。有很多常見的應用層協議是以 TCP 為基礎的，比如“FTP、SMTP、POP、IMAP”等。
TCP 被稱為“面向連線”的傳輸層協議。關於它的具體細節，俺就不展開了（否則篇幅又失控了）。你只需知道：傳輸層主要有兩個協議，分別是 TCP 和 UDP。TCP 比 UDP 更可靠。你可以把 TCP 協議想象成某個水管，傳送端這頭進水，接收端那頭就出水。並且 TCP 協議能夠確保，先發送的資料先到達（與之相反，UDP 不保證這點）。
3. HTTP 協議如何使用 TCP 連線 HTTP 對 TCP 連線的使用，分為兩種方式：俗稱“短連線”和“長連線”（“長連線”又稱“持久連線”，洋文叫做“Keep-Alive”或“Persistent
假設有一個網頁，裡面包含好多圖片，還包含好多【外部的】CSS 檔案和 JS 檔案。
在“短連線”的模式下，瀏覽器先發起一個 TCP 連線，拿到該網頁的 HTML 原始碼（拿到 HTML 之後，這個 TCP 連線就關閉了）。
然後，瀏覽器開始分析這個網頁的原始碼，知道這個頁面包含很多外部資源（圖片、CSS、JS）。
然後針對【每一個】外部資源，再分別發起一個個 TCP 連線，把這些檔案獲取到本地（同樣的，每抓取一個外部資源後，相應的 TCP 就斷開）
相反，如果是“長連線”的方式，瀏覽器也會先發起一個 TCP 連線去抓取頁面。但是抓取頁面之後，該 TCP 連線並不會立即關閉，而是暫時先保持著（所謂的“Keep-Alive”）。然後瀏覽器分析 HTML 原始碼之後，發現有很多外部資源，就用剛才那個 TCP 連線去抓取此頁面的外部資源。
在 HTTP 1.0 版本，【預設】使用的是“短連線”（那時候是 Web 誕生初期，網頁相對簡單，“短連線”的問題不大）；
到了1995年底開始制定 HTTP 1.1 草案的時候，網頁已經開始變得複雜（網頁內的圖片、指令碼越來越多了）。這時候再用短連線的方式，效率太低下了（因為建立 TCP 連線是有“時間成本”和“CPU 成本”滴）。
所以，在 HTTP 1.1 中，【預設】採用的是“Keep-Alive”的方式。
關於“Keep-Alive”的更多介紹，可以參見維基百科詞條（在“這裡”）
◇談談“對稱加密”和“非對稱加密”的概念（略）
◇CA 證書的原理及用途（略）
★HTTPS 協議的需求是啥？
花了好多口水，終於把背景知識說完了。下面正式進入正題。先來說說當初設計 HTTPS 是為了滿足哪些需求？
很多介紹 HTTPS 的文章一上來就給你講實現細節。個人覺得：這是不好的做法。早在2009年開博的時候，發過一篇《學習技術的三部曲：WHAT、HOW、WHY》，其中談到“WHY 型問題”的重要性。一上來就給你講協議細節，你充其量只能知道 WHAT 和 HOW，無法理解 WHY。俺在前一個章節講了“背景知識”，在這個章節講了“需求”，這就有助於你理解：當初為什麼要設計成這樣？——這就是 WHY 型的問題。
◇相容性
因為是先有 HTTP 再有 HTTPS。所以，HTTPS 的設計者肯定要考慮到對原有 HTTP 的相容性。這裡所說的相容性包括很多方面。比如已有的 Web 應用要儘可能無縫地遷移到 HTTPS；比如對瀏覽器廠商而言，改動要儘可能小；......
基於“相容性”方面的考慮，很容易得出如下幾個結論：
1. HTTPS 還是要基於 TCP 來傳輸
（如果改為 UDP 作傳輸層，無論是 Web 服務端還是瀏覽器客戶端，都要大改，動靜太大了）
2. 單獨使用一個新的協議，把 HTTP 協議包裹起來
（所謂的“HTTP over SSL”，實際上是在原有的 HTTP 資料外面加了一層 SSL 的封裝。HTTP 協議原有的 GET、POST 之類的機制，基本上原封不動）
打個比方：如果原來的 HTTP 是塑料水管，容易被戳破；那麼如今新設計的 HTTPS 就像是在原有的塑料水管之外，再包一層金屬水管。一來，原有的塑料水管照樣執行；二來，用金屬加固了之後，不容易被戳破。
◇可擴充套件性
前面說了，HTTPS 相當於是“HTTP over SSL”。如果 SSL 這個協議在“可擴充套件性”方面的設計足夠牛逼，那麼它除了能跟 HTTP 搭配，還能夠跟其它的應用層協議搭配。豈不美哉？
現在看來，當初設計 SSL 的人確實比較牛。如今的 SSL/TLS 可以跟很多常用的應用層協議（比如：FTP、SMTP、POP、Telnet）搭配，來強化這些應用層協議的安全性。
接著剛才打的比方：如果把 SSL/TLS 視作一根用來加固的金屬管，它不僅可以用來加固輸水的管道，還可以用來加固輸煤氣的管道。
◇保密性（防洩密）
HTTPS 需要做到足夠好的保密性。
說到保密性，首先要能夠對抗嗅探（行話叫 Sniffer）。所謂的“嗅探”，通俗而言就是監視你的網路傳輸流量。如果你使用明文的 HTTP 上網，那麼監視者通過嗅探，就知道你在訪問哪些網站的哪些頁面。
嗅探是最低階的攻擊手法。除了嗅探，HTTPS 還需要能對抗其它一些稍微高階的攻擊手法——比如“重放攻擊”（後面講協議原理的時候，會再聊）。
◇完整性（防篡改）
除了“保密性”，還有一個同樣重要的目標是“確保完整性”。關於“完整性”這個概念，在之前的博文《掃盲檔案完整性校驗——關於雜湊值和數字簽名》中大致提過。健忘的同學再去溫習一下。
在發明 HTTPS 之前，由於 HTTP 是明文的，不但容易被嗅探，還容易被篡改。
舉個例子：
比如咱們天朝的網路運營商（ISP）都比較流氓，經常有網友抱怨說訪問某網站（本來是沒有廣告的），竟然會跳出很多中國電信的廣告。為啥會這樣捏？因為你的網路流量需要經過 ISP 的線路才能到達公網。如果你使用的是明文的 HTTP，ISP 很容易就可以在你訪問的頁面中植入廣告。
所以，當初設計 HTTPS 的時候，還有一個需求是“確保 HTTP 協議的內容不被篡改”。
◇真實性（防假冒）
在談到 HTTPS 的需求時，“真實性”經常被忽略。其實“真實性”的重要程度不亞於前面的“保密性”和“完整性”。舉個例子：
你因為使用網銀，需要訪問該網銀的 Web 站點。那麼，你如何確保你訪問的網站確實是你想訪問的網站？（這話有點繞口令）
有些天真的同學會說：通過看網址裡面的域名，來確保。為啥說這樣的同學是“天真的”？因為 DNS 系統本身是不可靠的（尤其是在設計 SSL 的那個年代，連 DNSSEC 都還沒發明）。由於 DNS 的不可靠（存在“域名欺騙”和“域名劫持”），你看到的網址裡面的域名【未必】是真實滴！
（不瞭解“域名欺騙”和“域名劫持”的同學，可以參見俺之前寫的《掃盲 DNS 原理，兼談“域名劫持”和“域名欺騙/域名汙染”》）
所以，HTTPS 協議必須有某種機制來確保“真實性”的需求（至於如何確保，後面會細聊）。
◇效能
再來說最後一個需求——效能。引入 HTTPS 之後，【不能】導致效能變得太差。否則的話，誰還願意用？
為了確保效能，SSL 的設計者至少要考慮如下幾點：
1. 如何選擇加密演算法（“對稱”or“非對稱”）？
2. 如何兼顧 HTTP 採用的“短連線”TCP 方式？
（SSL 是在1995年之前開始設計的，那時候的 HTTP 版本還是 1.0，預設使用的是“短連線”的 TCP 方式——預設不啟用 Keep-Alive）
◇小結
以上就是設計 SSL 協議時，必須兼顧的各種需求。後面聊協議的實現時，俺會拿 SSL 協議的特點跟前面的需求作對照。看看這些需求是如何一一滿足滴。★設計 HTTPS 協議的主要難點
設計 HTTPS 這個協議，有好幾個難點。俺個人認為最大的難點在於“金鑰交換”。
在傳統的密碼學場景中，假如張三要跟李四建立一個加密通訊的渠道，雙方事先要約定好使用哪種加密演算法？同時也要約定好使用的金鑰是啥？在這個場景中，加密演算法的【型別】讓旁人知道，沒太大關係。但是金鑰【千萬不能】讓旁人知道。一旦旁人知道了金鑰，自然就可以破解通訊的密文，得到明文。
好，現在回到 HTTPS 的場景。
當你訪問某個公網的網站，你的瀏覽器和網站的伺服器之間，如果要建立加密通訊，必然要商量好雙方使用啥演算法，啥金鑰。 ——在網路通訊術語中，這個過程稱之為“握手/handshake”。在握手階段，因為加密方式還沒有協商好，所以握手階段的通訊必定是【明文】滴！既然是明文，自然有可能被第三方偷窺到。然後，還要考慮到雙方之間隔著一個網際網路，什麼樣的偷窺都可能發生。
因此，在握手的過程中，如何做到安全地交換金鑰資訊，而不讓周圍的第三方看到。這就是設計 HTTPS 最大的難點。
★結尾
本文費這麼多口水，來介紹 HTTPS 的“需求”和“難點”，為啥捏？因為只有當你瞭解這些，後面介紹 SSL/TLS 的實現原理時，你才能理解——當初為啥要把協議設計成這個樣子。
----------------------------------------------------分割線--------------------------------------------------------
掃盲HTTPS和SSL/TLS協議[2]
可靠祕鑰交換的原理
★先插播一個安全通告
就在本系列剛開播之後沒幾天（11月11日），微軟爆了一個 跟 SSL/TLS 相關的高危漏洞 ， 影響【幾乎所有的】Windows 平臺 。至此，【所有】主流的 SSL/TLS 協議棧（至少包括：開源的 OpenSSL、開源的 GnuTLS、微軟的 SSP、蘋果的 SecureTransport），全都在今年爆了高危漏洞。（看來俺這個系列生逢其時啊）個人覺得：【2014年】必將在資訊保安歷史上留下醒目的記錄。
用 Windows 系統的同學，這幾天要儘快升級微軟的“安全更新”。因為該漏洞會導致“遠端程式碼執行”，非常危險。
（微軟的公告中沒有提及 Win2000 和 WinXP 是因為這倆已經過了“產品支援週期”。不等於說這倆沒問題）
在本系列的前一篇，已經介紹了相關的背景知識以及設計 SSL 需要考慮的需求。當時俺提到：設計 HTTPS 的最大難點（沒有之一）是——如何在網際網路上進行安全的“金鑰交換”。今天就來講講金鑰交換的原理（暫不談技術實現）。
★方案1——單純用“對稱加密演算法”的可行性
首先簡單闡述一下，“單純用對稱加密”為啥是【不可行】滴。
如果“單純用對稱加密”，瀏覽器和網站之間勢必先要交換“對稱加密的金鑰”。
如果這個金鑰直接用【明文】傳輸，很容易就會被第三方（有可能是“攻擊者”）偷窺到；如果這個金鑰用密文傳輸，那就再次引入了“如何交換加密金鑰”的問題——這就變成“先有雞還是先有蛋”的迴圈邏輯了。
所以，【單純用】對稱加密，是沒戲滴。
★方案2——單純用“非對稱加密演算法”的風險
說完“對稱加密”，再來說說“非對稱加密”。在前面的“背景知識”中，已經大致介紹過“非對稱加密”的特點——“加密和解密採用不同的金鑰”。基於這個特點，可以避開前面提到的“迴圈邏輯”的困境。大致的步驟如下：
第1步
網站伺服器先基於“非對稱加密演算法”，隨機生成一個“金鑰對”（為敘述方便，稱之為“k1 和 k2”）。因為是隨機生成的，目前為止，只有網站伺服器才知道 k1 和 k2。
第2步
網站把 k1 保留在自己手中，把 k2 用【明文】的方式傳送給訪問者的瀏覽器。因為 k2 是明文傳送的，自然有可能被偷窺。不過不要緊。即使偷窺者拿到 k2，也【很難】根據 k2 推算出 k1（這一點是由“非對稱加密演算法”從數學上保證的）。
第3步
瀏覽器拿到 k2 之後，先【隨機生成】第三個對稱加密的金鑰（簡稱 k）。然後用 k2 加密 k，得到 k'（k' 是 k 的加密結果）瀏覽器把 k' 傳送給網站伺服器。由於 k1 和 k2 是成對的，所以只有 k1 才能解密 k2 的加密結果。因此這個過程中，即使被第三方偷窺，第三方也【無法】從 k' 解密得到 k
第4步
網站伺服器拿到 k' 之後，用 k1 進行解密，得到 k。至此，瀏覽器和網站伺服器就完成了金鑰交換，雙方都知道 k，而且【貌似】第三方無法拿到 k然後，雙方就可以用 k 來進行資料雙向傳輸的加密。現在，給大夥兒留一個思考時間——你覺得上述過程是否嚴密？如果不嚴密，漏洞在哪裡？OK，現在俺來揭曉答案。 “方案2”依然是不安全滴 ——雖然“方案2”可以在一定程度上防止網路資料的【偷窺/嗅探】，但是【無法】防範網路資料的【篡改】。
假設有一個攻擊者處於“瀏覽器”和“網站伺服器”的通訊線路之間，並且這個攻擊者具備“修改雙方傳輸資料”的能力。那麼，這個攻擊者就可以攻破“方案2”。具體的攻擊過程如下：
第1步
這一步跟原先一樣——伺服器先隨機生成一個“非對稱的金鑰對”k1 和 k2（此時只有網站知道 k1 和 k2）第2步
當網站傳送 k2 給瀏覽器的時候，攻擊者截獲 k2，保留在自己手上。然後攻擊者自己生成一個【偽造的】金鑰對（以下稱為 pk1 和 pk2）。攻擊者把 pk2 傳送給瀏覽器。
第3步
瀏覽器收到 pk2，以為 pk2 就是網站傳送的。瀏覽器不知情，依舊隨機生成一個對稱加密的金鑰 k，然後用 pk2 加密 k，得到密文的 k'瀏覽器把 k' 傳送給網站。（以下是關鍵）
傳送的過程中，再次被攻擊者截獲。因為 pk1 pk2 都是攻擊者自己生成的，所以攻擊者自然就可以用 pk1 來解密 k' 得到 k然後，攻擊者拿到 k 之後，用之前截獲的 k2 重新加密，得到 k''，並把 k'' 傳送給網站。
第4步
網站伺服器收到了 k'' 之後，用自己儲存的 k1 可以正常解密，所以網站方面不會起疑心。至此，攻擊者完成了一次漂亮的偷樑換柱，而且讓雙方都沒有起疑心。上述過程，也就是傳說中大名鼎鼎的“中間人攻擊” 。洋文叫做“Man-In-The-Middle attack”。縮寫是 MITM。“中間人攻擊”有很多種“型別”，剛才演示的是針對“【單純的】非對稱加密”的中間人攻擊。至於“中間人攻擊”的其它型別，俺在本系列的後續博文中，還會再提到。
★方案2失敗的根源——缺乏【可靠的】身份認證
為啥“方案2”會失敗？除了俺在圖中提到的“攻擊者具備篡改資料的能力”，還有另一點關鍵點——“方案2缺乏身份認證機制”。正是因為“缺乏身份認證機制”，所以當攻擊者一開始截獲 k2 並把自己偽造的 pk2 傳送給瀏覽器時，瀏覽器無法鑑別：自己收到的金鑰是不是真的來自於網站伺服器。假如具備某種【可靠的】身份認證機制，即使攻擊者能夠篡改資料，但是篡改之後的資料很容易被識破。那篡改也就失去了意義。★身份認證的幾種方式
下面，俺來介紹幾種常見的“身份認證原理”。◇基於某些“私密的共享資訊”
為了解釋“私密的共享資訊”這個概念，咱們先拋開“資訊保安”，談談日常生活中的某個場景。假設你有一個久未聯絡的老朋友。因為時間久遠，你已經沒有此人的聯絡方式了。某天，此人突然給你發了一封電子郵件。那麼，你如何確保——發郵件的人確實是你的老朋友捏？有一個辦法就是：你用郵件向對方詢問某個私密的事情（這個事情只有你和你的這個朋友知道，其他人不知道）。如果對方能夠回答出來，那麼對方【很有可能】確實是你的老朋友。從這個例子可以看出，如果通訊雙方具有某些“私密的共享資訊”（只有雙方知道，第三方不知道），就能以此為基礎，進行身份認證，從而建立信任。
◇基於雙方都信任的“公證人”
“私密的共享資訊”，通常需要雙方互相比較熟悉，才行得通。如果雙方本來就互不相識，如何進行身份認證以建立信任關係捏？這時候還有另一個辦法——依靠雙方都信任的某個“公證人”來建立信任關係。如今 C2C 模式的電子商務，其實用的就是這種方式——由電商平臺充當公證人，讓買家與賣家建立某種程度的信任關係。考慮到如今的網購已經相當普及，大夥兒應該對這類模式很熟悉吧。所以俺就不浪費口水了。★如何解決 SSL 的身份認證問題——CA 的引入
說完身份認證的方式/原理，再回到 SSL/TLS 的話題上。對於 SSL/TLS 的應用場景，由於雙方（“瀏覽器”和“網站伺服器”）通常都是互不相識的，顯然不可能採用第一種方式（私密的共享資訊），而只能採用第二種方式（依賴雙方都信任的“公證人”）。那麼，誰來充當這個公證人捏？這時候，CA 就華麗地登場啦。
所謂的 CA，就是“數字證書認證機構”的縮寫，洋文全稱叫做“Certificate Authority”。關於 CA 以及 CA 頒發的“CA 證書”，俺已經寫過一篇教程：《 數字證書及CA的掃盲介紹》，介紹其基本概念和功能。所以，此處就不再重複嘮叨了。如果你看完那篇 CA 的掃盲，你自然就明白——CA 完全有資格和能力，充當這個“公證人”的角色。
★方案3——基於 CA 證書進行金鑰交換
其實“方案3”跟“方案2”很像的，主要差別在於——“方案3”增加了“CA 數字證書”這個環節。所謂的數字證書，技術上依賴的還是前面提到的“非對稱加密”。為了描述“CA 證書”在 SSL/TLS 中的作用，俺大致說一下原理（僅僅是原理，具體的技術實現要略複雜些）：第1步（這是“一次性”的準備工作）
網站方面首先要花一筆銀子，在某個 CA 那裡購買一個數字證書。該證書通常會對應幾個檔案：其中一個檔案包含公鑰，還有一個檔案包含私鑰。此處的“私鑰”，相當於“方案2”裡面的 k1；而“公鑰”類似於“方案2”裡面的 k2。網站方面必須在 Web 伺服器上部署這兩個檔案。所謂的“公鑰”，顧名思義就是可以公開的 key；而所謂的“私鑰”就是私密的 key。其實前面已經說過了，這裡再嘮叨一下：“非對稱加密演算法”從數學上確保了——即使你知道某個公鑰，也很難（不是不可能，是很難）根據此公鑰推匯出對應的私鑰。
第2步
當瀏覽器訪問該網站，Web 伺服器首先把公鑰傳送給瀏覽器。
第3步
瀏覽器驗證網站發過來的證書。如果發現其中有詐，瀏覽器會提示“CA 證書安全警告”。由於有了這一步，就大大降低了（注意：是“大大降低”，而不是“徹底消除”）前面提到的“中間人攻擊”的風險。為啥瀏覽器能發現 CA 證書是否有詐？因為正經的 CA 證書，都是來自某個權威的 CA。如果某個 CA 足夠權威，那麼主流的作業系統（或瀏覽器）會內建該 CA 的“根證書”。（比如 Windows 中就內建了幾十個權威 CA 的根證書）因此，瀏覽器就可以利用系統內建的根證書，來判斷網站發過來的 CA 證書是不是某個 CA
頒發的。（關於“根證書”和“證書信任鏈”的概念，請參見之前的教程《 數字證書及CA的掃盲介紹 》）
第4步
如果網站發過來的 CA 證書沒有問題，那麼瀏覽器就從該 CA 證書中提取出“公鑰”。然後瀏覽器隨機生成一個“對稱加密的金鑰”（以下稱為 k）。用 CA 證書的公鑰加密 k，得到密文 k'，瀏覽器把 k' 傳送給網站。
第5步
網站收到瀏覽器發過來的 k'，用伺服器上的私鑰進行解密，得到 k。至此，瀏覽器和網站都擁有 k，“金鑰交換”大功告成啦。