前言
大家都知道，蘋果在2016年WWDC上宣布了關於應用需要強制使用HTTPS的規定。這也算是個好消息吧，雖然開發者們可能需要適配下HTTPS，但是我們的應用可算是披上一個安全的保護罩了。本篇文章就算是筆者在學習HTTPS過程中的一個記錄吧。
HTTPS加密過程
最近重新了解了下HTTP和HTTPS: 首先二者都是網絡傳輸協議;HTTPS在傳輸過程中是可以通過加密來保護數據安全的，以免用戶敏感信息被第三方獲取。 可以說HTTPS是HTTP的升級版、安全版。下面我們就簡單看下HTTPS的加密過程，先看下圖。
- 客戶端發起
HTTPS請求
這個沒什么好說的，就是用戶在瀏覽器里輸入一個HTTPS網址，然后連接到服務端的443端口。 - 服務端的配置
采用HTTPS協議的服務器必須要有一套數字證書，可以自己制作，也可以向組織申請。區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面。這套證書其實就是一對公鑰和私鑰。如果對公鑰不太理解，可以想象成一把鑰匙和一個鎖頭，只是世界上只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然后發給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。 - 傳送證書
這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發機構，過期時間等等。 - 客戶端解析證書
這部分工作是由客戶端的SSL/TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警示框，提示證書存在的問題。如果證書沒有問題，那么就生成一個隨機值。然后用證書（也就是公鑰）對這個隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內容。 - 傳送加密信息
這部分傳送的是用證書加密后的隨機值，目的是讓服務端得到這個隨機值，以后客戶端和服務端的通信就可以通過這個隨機值來進行加密解密了。 - 服務端解密信息
服務端用私鑰解密后，得到了客戶端傳過來的隨機值，然后把內容通過該隨機值進行對稱加密，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密算法夠彪悍，私鑰夠復雜，數據就夠安全。 - 傳輸加密后的信息
這部分信息就是服務端用私鑰加密后的信息，可以在客戶端用隨機值解密還原。 - 客戶端解密信息
客戶端用之前生產的私鑰解密服務端傳過來的信息，於是獲取了解密后的內容。整個過程第三方即使監聽到了數據，也束手無策。
到了這里，HTTPS的整個加密過程也就差不多完成了，但是這個過程中是不是還有些概念還是不太清楚，比如SSL是什么，TLS又是什么，他們是怎么驗證我們的證書是否有效的呢，它們的驗證策略又是怎樣的呢。別急，下面我們就討論下TLS。
TLS
剛開始聽到TLS的時候，你可能還不太熟悉，但是說起SSL你可能就覺得好耳熟了。其實TLS就是從SSL發展而來的，只是SSL發展到3.0版本后改成了TLS。
TLS主要提供三個基本服務
- 加密
- 身份驗證，也可以叫證書驗證吧~
- 消息完整性校驗
第三個是網絡協議中常用的一個校驗和機制，我這我們就先按下不表。
加密
我們再看一遍客戶端和服務端之間的加密機制：
TLS協議是基於TCP協議之上的，圖中第一個藍色往返是TCP的握手過程，之后兩次橙色的往返，我們可以叫做TLS的握手。握手過程如下：
-
client1：TLS版本號+所支持加密套件列表+希望使用的TLS選項 -
Server1:選擇一個客戶端的加密套件+自己的公鑰+自己的證書+希望使用的TLS選項+（要求客戶端證書）； -
Client2:(自己的證書)+使用服務器公鑰和協商的加密套件加密一個對稱秘鑰（自己生成的一個隨機值）； -
Server2:使用私鑰解密出對稱秘鑰（隨機值）后，發送加密的Finish消息，表明完成握手
這里可能要提一下什么是對稱加密和非對稱加密：
一般的對稱加密像這樣：
encrypt(明文，秘鑰) = 密文
decrypt(密文，秘鑰) = 明文
也就是說加密和解密用的是同一個秘鑰。而非對稱加密是這樣的：
encrypt(明文，公鑰) = 密文
decrypt(密文，私鑰) = 明文
加密和解密是需要不同的秘鑰的。
經過這幾次握手成功后，客服端和服務端之間通信的加密算法和所需要的密鑰也就確定下來了，之后雙方的交互都可以使用對稱加密算法加密了。
證書機制/證書驗證
在TLS中，我們需要證書來保證你所訪問的服務器是真實的，可信的。
看這張圖我們來討論下證書的驗證過程。
- 客戶端獲取到了站點證書，拿到了站點的公鑰；
- 要驗證站點可信后，才能使用其公鑰，因此客戶端找到其站點證書頒發者的信息；
- 站點證書的頒發者驗證了服務端站點是可信的，但客戶端依然不清楚該頒發者是否可信；
- 再往上回溯，找到了認證了中間證書商的源頭證書頒發者。由於源頭的證書頒發者非常少，我們瀏覽器之前就認識了，因此可以認為根證書頒發者是可信的；
- 一路倒推，證書頒發者可信，那么它所頒發的所有站點也是可信的，最終確定了我們所訪問的服務端是可信的；
- 客戶端使用證書中的公鑰，繼續完成
TLS的握手過程。
那么，客戶端是是如何驗證某個證書的有效性，或者驗證策略是怎樣的?
證書頒發者一般提供兩種方式來驗證證書的有效性：CRL和OCSP。
CRL
CRL（Certificate Revocation List）即證書撤銷名單。證書頒發者會提供一份已經失效證書的名單，供瀏覽器驗證證書使用。當然這份名單是巨長無比的，瀏覽器不可能每次TLS都去下載，所以常用的做法是瀏覽器會緩存這份名單，定期做后台更新。這樣雖然后台更新存在時間間隔，證書失效不實時，但一般也OK。
OCSP
OCSP(Online Certificate StatusProtocol)即在線證書狀態協議。除了離線文件，證書頒發者也會提供實時的查詢接口，查詢某個特定證書目前是否有效。實時查詢的問題在於瀏覽器需要等待這個查詢結束才能繼續TLS握手，延遲會更大。
以上是站點在證書頒發者的角度說明會提供的兩種判斷方式，實際情況下瀏覽器究竟會選擇哪種方式判斷，每個瀏覽器都會有自己的實現。下面是通過Chrome查看GitHub網站的證書信息：
到這里差不多了，有什么不對的地方，歡迎大家留言指出，一起學習進步！
筆者不才，有些地方還是理解不到位，若有不正之處，還請耐心指出，輕噴~。
參看文章
鏈接：https://www.jianshu.com/p/f6b34381beac