博文出處：HTTPS加密原理，歡迎大家關注我的博客，謝謝！
Header
HTTP、HTTPS在我們日常開發(fā)中是經(jīng)常會接觸到的。
我們也都知道，一般 Android 應用開發(fā)，在請求 API 網(wǎng)絡接口的時候，很多使用的都是 HTTP 協(xié)議；使用瀏覽器打開網(wǎng)頁，也是利用 HTTP 協(xié)議?？磥?HTTP 真是使用廣泛啊，但是，HTTP 是不安全的。利用網(wǎng)絡抓包工具就可以知道傳輸中的內容，一覽無余。比如我經(jīng)常會使用 Fiddler 來抓包，搜集一些有趣的 API 接口。
那么問題來了，如何保證 HTTP 的安全性呢？基本上所有的人都會脫口而出：使用 HTTPS 協(xié)議。99.9% 的人都知道 HTTPS 會將傳輸?shù)膬热葸M行加密，但是接著問具體加密的過程和步驟，很多人就啞口無言了。
為了防止出現(xiàn)這種尷尬的局面，所以今天你就要好好看看這篇的內容了。以后就可以裝個逼，哈哈！
Body
加密類型
先科普一下，加密算法的類型基本上分為了兩種：
- 對稱加密，比較有代表性的就是 AES 加密算法；
- 非對稱加密，經(jīng)常使用到的 RSA 加密算法就是非對稱加密的；
對稱加密的意思就是說雙方都有一個共同的密鑰，然后通過這個密鑰完成加密和解密，這種加密方式速度快，但是安全性不如非對稱加密好。
舉個例子，現(xiàn)在學霸小明這里有一道數(shù)學題的答案：123 。他想把答案傳給自己一直暗戀的小紅。所以他們雙方在考試開考前，約定了一把密鑰：456 。那么小明就把答案內容經(jīng)過密鑰加密，即 123 + 456 = 579 ，將 579 寫在小紙條上扔給小紅。如果此時別人撿到了小紙條，不知道他們是加密傳輸?shù)模吹缴厦娴?579 ，會誤以為答案就是 579 ；如果是小紅撿到了，她拿出密鑰解密，579 - 456 = 123 ，得到了正確的答案。
這就是所謂的對稱加密，加解密效率高，速度快，但是雙方任何一方不小心泄露了密鑰，那么任何人都可以知道傳輸內容了。
講完了對稱加密，我們看看啥是非對稱加密。
非對稱加密就是有兩把密鑰，公鑰和私鑰。私鑰自己藏著，不告訴任何人；而公鑰可以公開給別人。
經(jīng)過了上次作弊后，小紅發(fā)現(xiàn)了對稱加密如果密鑰泄露是一件可怕的事情。所以她和小明決定使用非對稱加密。小紅生成了一對公鑰和私鑰，然后把公鑰公開，小明就得到了公鑰。小明拿到公鑰后，把答案經(jīng)過公鑰加密，然后傳輸給小紅，小紅再利用自己的私鑰進行解密，得到答案結果。如果在這個過程中，其他人得到傳輸?shù)膬热荩麄冎挥行〖t公鑰，是沒有辦法進行解密的，所以也就得不到答案，只有小紅一個人可以解密。
因此，相比較對稱加密而言，非對稱加密安全性更高，但是加解密耗費的時間更長，速度慢。
對稱加密和非對稱加密的具體應用我還是深有體會的，因為所在的公司是做金融支付方面的，所以加解密基本上算是天天見了。
HTTPS
說完加密類型后，我們再來看看 HTTPS 。
我們先來看一個公式：
HTTPS = HTTP + SSL
從這個公式中可以看出，HTTPS 和 HTTP 就差在了 SSL 上。所以我們可以猜到，HTTPS 的加密就是在 SSL 中完成的。
所以我們的目的就是要搞懂在 SSL 中究竟干了什么見不得人的事了？
這就要從 CA 證書講起了。CA 證書其實就是數(shù)字證書，是由 CA 機構頒發(fā)的。至于 CA 機構的權威性，那么是毋庸置疑的，所有人都是信任它的。CA 證書內一般會包含以下內容：
- 證書的頒發(fā)機構、版本
- 證書的使用者
- 證書的公鑰
- 證書的有效時間
- 證書的數(shù)字簽名 Hash 值和簽名 Hash 算法
- ...
正好我們把客戶端如何校驗 CA 證書的步驟說下吧。
CA 證書中的 Hash 值，其實是用證書的私鑰進行加密后的值（證書的私鑰不在 CA 證書中）。然后客戶端得到證書后，利用證書中的公鑰去解密該 Hash 值，得到 Hash-a ；然后再利用證書內的簽名 Hash 算法去生成一個 Hash-b 。最后比較 Hash-a 和 Hash-b 這兩個的值。如果相等，那么證明了該證書是對的，服務端是可以被信任的；如果不相等，那么就說明該證書是錯誤的，可能被篡改了，瀏覽器會給出相關提示，無法建立起 HTTPS 連接。除此之外，還會校驗 CA 證書的有效時間和域名匹配等。
接下來我們就來詳細講一下 HTTPS 中的 SSL 握手建立過程，假設現(xiàn)在有客戶端 A 和服務器 B ：
- 首先，客戶端 A 訪問服務器 B ，比如我們用瀏覽器打開一個網(wǎng)頁 https://www.baidu.com ，這時，瀏覽器就是客戶端 A ，百度的服務器就是服務器 B 了。這時候客戶端 A 會生成一個隨機數(shù)1，把隨機數(shù)1 、自己支持的 SSL 版本號以及加密算法等這些信息告訴服務器 B 。
- 服務器 B 知道這些信息后，然后確認一下雙方的加密算法，然后服務端也生成一個隨機數(shù) B ，并將隨機數(shù) B 和 CA 頒發(fā)給自己的證書一同返回給客戶端 A 。
- 客戶端 A 得到 CA 證書后，會去校驗該 CA 證書的有效性，校驗方法在上面已經(jīng)說過了。校驗通過后，客戶端生成一個隨機數(shù)3 ，然后用證書中的公鑰加密隨機數(shù)3 并傳輸給服務端 B 。
- 服務端 B 得到加密后的隨機數(shù)3，然后利用私鑰進行解密，得到真正的隨機數(shù)3。
- 最后，客戶端 A 和服務端 B 都有隨機數(shù)1、隨機數(shù)2、隨機數(shù)3，然后雙方利用這三個隨機數(shù)生成一個對話密鑰。之后傳輸內容就是利用對話密鑰來進行加解密了。這時就是利用了對稱加密，一般用的都是 AES 算法。
- 客戶端 A 通知服務端 B ，指明后面的通訊用對話密鑰來完成，同時通知服務器 B 客戶端 A 的握手過程結束。
- 服務端 B 通知客戶端 A，指明后面的通訊用對話密鑰來完成，同時通知客戶端 A 服務器 B 的握手過程結束。
- SSL 的握手部分結束，SSL 安全通道的數(shù)據(jù)通訊開始，客戶端 A 和服務器 B 開始使用相同的對話密鑰進行數(shù)據(jù)通訊。
到此，SSL 握手過程就講完了。可能上面的流程太過于復雜，我們簡單地來講：
- 客戶端和服務端建立 SSL 握手，客戶端通過 CA 證書來確認服務端的身份；
- 互相傳遞三個隨機數(shù)，之后通過這隨機數(shù)來生成一個密鑰；
- 互相確認密鑰，然后握手結束；
- 數(shù)據(jù)通訊開始，都使用同一個對話密鑰來加解密；
我們可以發(fā)現(xiàn)，在 HTTPS 加密原理的過程中把對稱加密和非對稱加密都利用了起來。即利用了非對稱加密安全性高的特點，又利用了對稱加密速度快，效率高的好處。真的是設計得非常精妙，令人贊不絕口。
Footer
好了，HTTPS 加密原理到這就講的差不多了，不知道電腦前的你有沒有看懂呢？
如果有哪里不明白的地方，可以在底下留言交流。
bye ~~
