HTTPS 為什麼更安全，先看這些

02-02

HTTPS 是建立在密碼學基礎之上的一種安全通信協議，嚴格來說是基於 HTTP 協議和 SSL/TLS 的組合。理解 HTTPS 之前有必要弄清楚一些密碼學的相關基礎概念，比如：明文、密文、密碼、密鑰、對稱加密、非對稱加密、信息摘要、數字簽名、數字證書。接下來我會逐個解釋這些術語，文章裡面提到的『數據』、『消息』都是同一個概念，表示用戶之間通信的內容載體，此外文章中提到了以下幾個角色：

Alice：消息發送者
Bob：消息接收者
Attacker：中間攻擊者
Trent：第三方認證機構

密碼

密碼學中的「密碼」術語與網站登錄時用的密碼（password）是不一樣的概念，password 翻譯過來其實是「口令」，它是用於認證用途的一組文本字元串。

而密碼學中的密碼（cipher）是一套演算法(algorithm)，這套演算法用於對消息進行加密和解密，從明文到密文的過程稱之為加密，密文反過來生成明文稱之為解密，加密演算法與解密演算法合在一起稱為密碼演算法。

密鑰

密鑰（key）是在使用密碼演算法過程中輸入的一段參數。同一個明文在相同的密碼演算法和不同的密鑰計算下會產生不同的密文。很多知名的密碼演算法都是公開的，密鑰才是決定密文是否安全的重要參數，通常密鑰越長，破解的難度越大，比如一個8位的密鑰最多有256種情況，使用窮舉法，能非常輕易的破解。根據密鑰的使用方法，密碼可分為對稱加密和公鑰加密。

對稱加密

對稱密鑰（Symmetric-key algorithm）又稱為共享密鑰加密，加密和解密使用相同的密鑰。常見的對稱加密演算法有DES、3DES、AES、RC5、RC6。對稱密鑰的優點是計算速度快，但是它有缺點，接收者需要發送者告知密鑰才能解密，因此密鑰如何安全的發送給接收者成為了一個問題。

Alice 給 Bob 發送數據時，把數據用對稱加密後發送給 Bob，發送過程中由於對數據進行了加密，因此即使有人竊取了數據也沒法破解，因為它不知道密鑰是什麼。但是同樣的問題是 Bob 收到數據後也一籌莫展，因為它也不知道密鑰是什麼，那麼 Alice 是不是可以把數據和密鑰一同發給 Bob 呢。當然不行，一旦把密鑰和密鑰一起發送的話，那就跟發送明文沒什麼區別了，因為一旦有人把密鑰和數據同時獲取了，密文就破解了。所以對稱加密的密鑰配是個問題。如何解決呢，公鑰加密是一個辦法。

公鑰加密

公開密鑰加密（public-key cryptography）簡稱公鑰加密，這套密碼演算法包含配對的密鑰對，分為加密密鑰和解密密鑰。發送者用加密密鑰進行加密，接收者用解密密鑰進行解密。加密密鑰是公開的，任何人都可以獲取，因此加密密鑰又稱為公鑰（public key），解密密鑰不能公開，只能自己使用，因此它又稱為私鑰（private key）。常見的公鑰加密演算法有 RSA。

還是以Alice 給 Bob 發送數據為例，公鑰加密演算法由接收者 Bob 發起

Bob 生成公鑰和私鑰對，私鑰自己保存，不能透露給任何人。
Bob 把公鑰發送給 Alice，發送過程中即使被人竊取也沒關係
Alice 用公鑰把數據進行加密，並發送給 Bob，發送過程中被人竊取了同樣沒關係，因為沒有配對的私鑰進行解密是沒法破解的
Bob 用配對的私鑰解密。

雖然公鑰加密解決了密鑰配送的問題，但是你沒法確認公鑰是不是合法的，Bob 發送的公鑰你不能肯定真的是 Bob 發的，因為也有可能在 Bob 把公鑰發送給 Alice 的過程中出現中間人攻擊，把真實的公鑰掉包替換。而對於 Alice 來說完全不知。還有一個缺點是它的運行速度比對稱加密慢很多。

消息摘要

消息摘要（message digest）函數是一種用於判斷數據完整性的演算法，也稱為散列函數或哈希函數，函數返回的值叫散列值，散列值又稱為消息摘要或者指紋（fingerprint）。這種演算法是一個不可逆的演算法，因此你沒法通過消息摘要反向推倒出消息是什麼。所以它也稱為單向散列函數。下載軟體時如何確定是官方提供的完整版呢，如果有中間人在軟體裡面嵌入了病毒，你也不得而知。所以我們可以使用散列函數對消息進行運算，生成散列值，通常軟體提供方會同時提供軟體的下載地址和軟體的散列值，用戶把軟體下載後在本地用相同的散列演算法計算出散列值，與官方提供的散列值對比，如果相同，說明該軟體是完成的，否則就是被人修改過了。常用的散列演算法有MD5、SHA。

下載 Eclipse 時，官方網站同時提供了軟體地址和消息摘要

散列函數可以保證數據的完整性，識別出數據是否被篡改，但它並不能識別出數據是不是偽裝的，因為中間人可以把數據和消息摘要同時替換，數據雖然是完整的，但真實數據被掉包了，接收者收到的並不是發送者發的，而是中間人的。消息認證是解決數據真實性的辦法。認證使用的技術有消息認證碼和數字簽名。

消息認證碼

消息認證碼（message authentication code）是一種可以確認消息完整性並進行認證（消息認證是指確認消息來自正確的發送者）的技術，簡稱 MAC。消息認證碼可以簡單理解為一種與密鑰相關的單向散列函數。

Alice 給 Bob 發送消息前，先把共享密鑰（key）發送給 Bob，Alice 把消息計算出 MAC 值，連同消息一起發送給 Bob，Bob 接收到消息和 MAC 值後，與本地計算得到 MAC 值對比，如果兩者相同，就說明消息是完整的，而且可以確定是 Alice 發送的，沒有中間人偽造。不過，消息認證碼同樣會遇到對稱加密的密鑰配送問題，因此解決密鑰配送問題還是要採用公鑰加密的方式。

此外，消息認證碼還有一個無法解決的問題，Bob 雖然可以識別出消息的篡改和偽裝，但是 Alice 可以否認說：「我沒發消息，應該是 Bob 的密鑰被 Attacker 盜取了，這是 Attacker 發的吧」。Alice 這麼說你還真沒什麼可以反駁的，那麼如何防止 Alice 不承認呢，數字簽名可以實現。

數字簽名

Alice 發郵件找 Bob 借1萬錢，因為郵件可以被人篡改（改成10萬），也可以被偽造（Alice 根本就沒發郵件，而是 Attacker 偽造 Alice 在發郵件），Alice 借了錢之後還可以不承認（不是我借的，我沒有簽名啊）。

消息認證碼可以解決篡改和偽造的問題，Alice 不承認自己借了錢時，Bob 去找第三方機構做公正，即使這樣，公正方也沒法判斷 Alice 有沒有真的借錢，因為他們倆共享了密鑰，也就是說兩個都可以計算出正確的 MAC 值，Bob 說：「明明你發的消息和 MAC 值和我自己生成的 MAC 值一樣，肯定是你發的消息」，Alice 說：「你把密鑰透露給了其他人，是他發的郵件，你找他去吧」。Alice 矢口否認。

數字簽名（Digital Signature）就可以解決否認的問題，發送消息時，Alice 和 Bob 使用不同的密鑰，把公鑰加密演算法反過來使用，發送者 Alice 使用私鑰對消息進行簽名，而且只能是擁有私鑰的 Alice 可以對消息簽名，Bob 用配對的公鑰去驗證簽名，第三方機構也可以用公鑰驗證簽名，如果驗證通過，說明消息一定是 Alice 發送的，抵賴也不行，因為你只有 Alice 可以生成簽名。這就防止了否認的問題。

它的流程是:

第一步：發送者 Alice 把消息哈希函數處理生成消息摘要，摘要信息使用私鑰加密之後生成簽名，連同消息一起發送給接收者 Bob。

第二步：數據經過網路傳輸，Bob收到數據後，把簽名和消息分別提取出來。

第三步：對簽名進行驗證，驗證的過程是先把消息提取出來做同樣的Hash處理，得到消息摘要，再與 Alice 傳過來的簽名用公鑰解密，如果兩者相等，就表示簽名驗證成功，否則驗證失敗，表示不是 Alice發的。

公鑰證書

公鑰密碼在數字簽名技術裡面扮演舉足輕重的角色，但是如何保證公鑰是合法的呢，如果是遭到中間人攻擊，掉包怎麼辦？這個時候公鑰就應該交給一個第三方權威機構來管理，這個機構就是認證機構（Certification Authority）CA，CA 把用戶的姓名、組織、郵箱地址等個人信息收集起來，還有此人的公鑰，並由 CA 提供數字簽名生成公鑰證書（Public-Key Certificate）PKC，簡稱證書。

Alice 向 Bob 發送消息時，是通過 Bob 提供的公鑰加密後的數據，而 Alice 獲取的公鑰並不是由 Bob 直接給的，而是由委託一個受信任的第三方機構給的。

Bob 生成密鑰對，私鑰自己保管，公鑰交給認證機構 Trent。
Trent 經過一系列嚴格的檢查確認公鑰是 Bob 本人的
Trent 事先也生成自己的一套密鑰對，用自己的私鑰對 Bob 的公鑰進行數字簽名並生成數字證書。證書中包含了 Bob 的公鑰。公鑰在這裡是不需要加密的，因為任何人獲取 Bob 的公鑰都沒事，只要確定是 Bob 的公鑰就行。
Alice 獲取 Trent 提供的證書。
Alice 用 Trent 提供的公鑰對證書進行簽名驗證，簽名驗證成功就表示證書中的公鑰是 Bob 的。
於是 Alice 就可以用 Bob 提供的公鑰對消息加密後發送給 Bob。
Bob 收到密文後，用與之配對的私鑰進行解密。

至此，一套比較完善的數據傳輸方案就完成了。HTTPS（SSL/TLS）就是在這樣一套流程基礎之上建立起來的。

本文首發於公眾號『Python之禪』（id:VTtalk），分享 Python 等技術乾貨和有溫度的內容，歡迎關注
博客地址：https://foofish.net/https-story-1.html