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

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 發起

1. Bob 生成公鑰和私鑰對，私鑰自己儲存，不能透露給任何人。
2. Bob 把公鑰傳送給 Alice，傳送過程中即使被人竊取也沒關係
3. Alice 用公鑰把資料進行加密，併傳送給 Bob，傳送過程中被人竊取了同樣沒關係，因為沒有配對的私鑰進行解密是沒法破解的
4. 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 直接給的，而是由委託一個受信任的第三方機構給的。

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

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