HTTPS加密原理(轉)

Header

HTTP、HTTPS在我們日常開發中是經常會接觸到的。

我們也都知道，一般 Android 應用開發，在請求 API 網絡接口的時候，很多使用的都是 HTTP 協議；使用瀏覽器打開網頁，也是利用 HTTP 協議。看來 HTTP 真是使用廣泛啊，但是，HTTP 是不安全的。利用網絡抓包工具就可以知道傳輸中的內容，一覽無余。比如我經常會使用 Fiddler 來抓包，搜集一些有趣的 API 接口。

那么問題來了，如何保證 HTTP 的安全性呢？基本上所有的人都會脫口而出：使用 HTTPS 協議。99.9% 的人都知道 HTTPS 會將傳輸的內容進行加密，但是接着問具體加密的過程和步驟，很多人就啞口無言了。

為了防止出現這種尷尬的局面，所以今天你就要好好看看這篇的內容了。以后就可以裝個逼，哈哈！

Body

加密類型

先科普一下，加密算法的類型基本上分為了兩種：

• 對稱加密，比較有代表性的就是 AES 加密算法；
• 非對稱加密，經常使用到的 RSA 加密算法就是非對稱加密的；

對稱加密的意思就是說雙方都有一個共同的密鑰，然后通過這個密鑰完成加密和解密，這種加密方式速度快，但是安全性不如非對稱加密好。

舉個例子，現在學霸小明這里有一道數學題的答案：123 。他想把答案傳給自己一直暗戀的小紅。所以他們雙方在考試開考前，約定了一把密鑰：456 。那么小明就把答案內容經過密鑰加密，即 123 + 456 =  579 ，將 579 寫在小紙條上扔給小紅。如果此時別人撿到了小紙條，不知道他們是加密傳輸的，看到上面的 579 ，會誤以為答案就是 579 ；如果是小紅撿到了，她拿出密鑰解密，579 - 456 = 123 ，得到了正確的答案。

這就是所謂的對稱加密，加解密效率高，速度快，但是雙方任何一方不小心泄露了密鑰，那么任何人都可以知道傳輸內容了。

講完了對稱加密，我們看看啥是非對稱加密。

非對稱加密就是有兩把密鑰，公鑰和私鑰。私鑰自己藏着，不告訴任何人；而公鑰可以公開給別人。

經過了上次作弊后，小紅發現了對稱加密如果密鑰泄露是一件可怕的事情。所以她和小明決定使用非對稱加密。小紅生成了一對公鑰和私鑰，然后把公鑰公開，小明就得到了公鑰。小明拿到公鑰后，把答案經過公鑰加密，然后傳輸給小紅，小紅再利用自己的私鑰進行解密，得到答案結果。如果在這個過程中，其他人得到傳輸的內容，而他們只有小紅公鑰，是沒有辦法進行解密的，所以也就得不到答案，只有小紅一個人可以解密。

因此，相比較對稱加密而言，非對稱加密安全性更高，但是加解密耗費的時間更長，速度慢。

對稱加密和非對稱加密的具體應用我還是深有體會的，因為所在的公司是做金融支付方面的，所以加解密基本上算是天天見了。

HTTPS

說完加密類型后，我們再來看看 HTTPS 。

我們先來看一個公式：

HTTPS = HTTP + SSL

從這個公式中可以看出，HTTPS 和 HTTP 就差在了 SSL 上。所以我們可以猜到，HTTPS 的加密就是在 SSL 中完成的。

所以我們的目的就是要搞懂在 SSL 中究竟干了什么見不得人的事了？

這就要從 CA 證書講起了。CA 證書其實就是數字證書，是由 CA 機構頒發的。至於 CA 機構的權威性，那么是毋庸置疑的，所有人都是信任它的。CA 證書內一般會包含以下內容：

• 證書的頒發機構、版本
• 證書的使用者
• 證書的公鑰
• 證書的有效時間
• 證書的數字簽名 Hash 值和簽名 Hash 算法
• …

正好我們把客戶端如何校驗 CA 證書的步驟說下吧。

CA 證書中的 Hash 值，其實是用證書的私鑰進行加密后的值（證書的私鑰不在 CA 證書中）。然后客戶端得到證書后，利用證書中的公鑰去解密該 Hash 值，得到 Hash-a ；然后再利用證書內的簽名 Hash 算法去生成一個 Hash-b 。最后比較 Hash-a 和 Hash-b 這兩個的值。如果相等，那么證明了該證書是對的，服務端是可以被信任的；如果不相等，那么就說明該證書是錯誤的，可能被篡改了，瀏覽器會給出相關提示，無法建立起 HTTPS 連接。除此之外，還會校驗 CA 證書的有效時間和域名匹配等。

接下來我們就來詳細講一下 HTTPS 中的 SSL 握手建立過程，假設現在有客戶端 A 和服務器 B ：

1. 首先，客戶端 A 訪問服務器 B ，比如我們用瀏覽器打開一個網頁 https://www.baidu.com ，這時，瀏覽器就是客戶端 A ，百度的服務器就是服務器 B 了。這時候客戶端 A 會生成一個隨機數1，把隨機數1 、自己支持的 SSL 版本號以及加密算法等這些信息告訴服務器 B 。
2. 服務器 B 知道這些信息后，然后確認一下雙方的加密算法，然后服務端也生成一個隨機數 B ，並將隨機數 B 和 CA 頒發給自己的證書一同返回給客戶端 A 。
3. 客戶端 A 得到 CA 證書后，會去校驗該 CA 證書的有效性，校驗方法在上面已經說過了。校驗通過后，客戶端生成一個隨機數3 ，然后用證書中的公鑰加密隨機數3 並傳輸給服務端 B 。
4. 服務端 B 得到加密后的隨機數3，然后利用私鑰進行解密，得到真正的隨機數3。
5. 最后，客戶端 A 和服務端 B 都有隨機數1、隨機數2、隨機數3，然后雙方利用這三個隨機數生成一個對話密鑰。之后傳輸內容就是利用對話密鑰來進行加解密了。這時就是利用了對稱加密，一般用的都是 AES 算法。
6. 客戶端 A 通知服務端 B ，指明后面的通訊用對話密鑰來完成，同時通知服務器 B 客戶端 A 的握手過程結束。
7. 服務端 B 通知客戶端 A，指明后面的通訊用對話密鑰來完成，同時通知客戶端 A 服務器 B 的握手過程結束。
8. SSL 的握手部分結束，SSL 安全通道的數據通訊開始，客戶端 A 和服務器 B 開始使用相同的對話密鑰進行數據通訊。

到此，SSL 握手過程就講完了。可能上面的流程太過於復雜，我們簡單地來講：

1. 客戶端和服務端建立 SSL 握手，客戶端通過 CA 證書來確認服務端的身份；
2. 互相傳遞三個隨機數，之后通過這隨機數來生成一個密鑰；
3. 互相確認密鑰，然后握手結束；
4. 數據通訊開始，都使用同一個對話密鑰來加解密；

我們可以發現，在 HTTPS 加密原理的過程中把對稱加密和非對稱加密都利用了起來。即利用了非對稱加密安全性高的特點，又利用了對稱加密速度快，效率高的好處。真的是設計得非常精妙，令人贊不絕口。

reference: 鏈接1 鏈接2