HTTPS加密過程和TLS證書驗證

前言

你們都知道，蘋果在2016年WWDC上宣佈了關於應用須要強制使用HTTPS的規定。這也算是個好消息吧，雖然開發者們可能須要適配下HTTPS，可是咱們的應用可算是披上一個安全的保護罩了。本篇文章就算是筆者在學習HTTPS過程當中的一個記錄吧。

HTTPS加密過程

最近從新瞭解了下HTTP和HTTPS: 首先兩者都是網絡傳輸協議;HTTPS在傳輸過程當中是能夠經過加密來保護數據安全的，以避免用戶敏感信息被第三方獲取。 能夠說HTTPS是HTTP的升級版、安全版。下面咱們就簡單看下HTTPS的加密過程，先看下圖。

1. 客戶端發起HTTPS請求 這個沒什麼好說的，就是用戶在瀏覽器裏輸入一個HTTPS網址，而後鏈接到服務端的443端口。
2. 服務端的配置 採用HTTPS協議的服務器必需要有一套數字證書，能夠本身製做，也能夠向組織申請。區別就是本身頒發的證書須要客戶端驗證經過，才能夠繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面。這套證書其實就是一對公鑰和私鑰。若是對公鑰不太理解，能夠想象成一把鑰匙和一個鎖頭，只是世界上只有你一我的有這把鑰匙，你能夠把鎖頭給別人，別人能夠用這個鎖把重要的東西鎖起來，而後發給你，由於只有你一我的有這把鑰匙，因此只有你才能看到被這把鎖鎖起來的東西。
3. 傳送證書 這個證書其實就是公鑰，只是包含了不少信息，如證書的頒發機構，過時時間等等。
4. 客戶端解析證書 這部分工做是由客戶端的SSL/TLS來完成的，首先會驗證公鑰是否有效，好比頒發機構，過時時間等等，若是發現異常，則會彈出一個警示框，提示證書存在的問題。若是證書沒有問題，那麼就生成一個***隨機值***。而後用證書（也就是公鑰）對這個隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，否則看不到被鎖住的內容。
5. 傳送加密信息 這部分傳送的是用證書加密後的隨機值，目的是讓服務端獲得這個隨機值，之後客戶端和服務端的通訊就能夠經過這個隨機值來進行加密解密了。
6. 服務端解密信息 服務端用私鑰解密後，獲得了客戶端傳過來的隨機值，而後把內容經過該隨機值進行對稱加密，將信息和私鑰經過某種算法混合在一塊兒，這樣除非知道私鑰，否則沒法獲取內容，而正好客戶端和服務端都知道這個私鑰，因此只要加密算法夠彪悍，私鑰夠複雜，數據就夠安全。
7. 傳輸加密後的信息 這部分信息就是服務端用私鑰加密後的信息，能夠在客戶端用隨機值解密還原。
8. 客戶端解密信息 客戶端用以前生產的私鑰解密服務端傳過來的信息，因而獲取瞭解密後的內容。整個過程第三方即便監聽到了數據，也一籌莫展。

到了這裏，HTTPS的整個加密過程也就差很少完成了，可是這個過程當中是否是還有些概念仍是不太清楚，好比SSL是什麼，TLS又是什麼，他們是怎麼驗證咱們的證書是否有效的呢，它們的驗證策略又是怎樣的呢。別急，下面咱們就討論下TLS。

TLS

剛開始聽到TLS的時候，你可能還不太熟悉，可是提及SSL你可能就以爲好耳熟了。其實TLS就是從SSL發展而來的，只是SSL發展到3.0版本後改爲了TLS。

TLS主要提供三個基本服務

• 加密
• 身份驗證，也能夠叫證書驗證吧~
• 消息完整性校驗

第三個是網絡協議中經常使用的一個校驗和機制，我這咱們就先按下不表。

加密

咱們再看一遍客戶端和服務端之間的加密機制：

TLS協議是基於TCP協議之上的，圖中第一個藍色往返是TCP的握手過程，以後兩次橙色的往返，咱們能夠叫作TLS的握手。握手過程以下：

1. client1：TLS版本號+所支持加密套件列表+但願使用的TLS選項
2. Server1:選擇一個客戶端的加密套件+本身的公鑰+本身的證書+但願使用的TLS選項+（要求客戶端證書）；
3. Client2:(本身的證書)+使用服務器公鑰和協商的加密套件加密一個對稱祕鑰（本身生成的一個隨機值）；
4. Server2:使用私鑰解密出對稱祕鑰（隨機值）後，發送加密的Finish消息，代表完成握手

這裏可能要提一下什麼是對稱加密和非對稱加密： 通常的對稱加密像這樣：

encrypt(明文，祕鑰) = 密文
decrypt(密文，祕鑰) = 明文
複製代碼

也就是說加密和解密用的是同一個祕鑰。而非對稱加密是這樣的：

encrypt(明文，公鑰) = 密文
decrypt(密文，私鑰) = 明文
複製代碼

加密和解密是須要不一樣的祕鑰的。

通過這幾回握手成功後，客服端和服務端之間通訊的加密算法和所須要的密鑰也就肯定下來了，以後雙方的交互均可以使用對稱加密算法加密了。

證書機制/證書驗證

在TLS中，咱們須要證書來保證你所訪問的服務器是真實的，可信的。 看這張圖咱們來討論下證書的驗證過程。

1. 客戶端獲取到了站點證書，拿到了站點的公鑰；
2. 要驗證站點可信後，才能使用其公鑰，所以客戶端找到其站點證書頒發者的信息；
3. 站點證書的頒發者驗證了服務端站點是可信的，但客戶端依然不清楚該頒發者是否可信；
4. 再往上回溯，找到了認證了中間證書商的源頭證書頒發者。因爲源頭的證書頒發者很是少，咱們瀏覽器以前就認識了，所以能夠認爲根證書頒發者是可信的；
5. 一路倒推，證書頒發者可信，那麼它所頒發的全部站點也是可信的，最終肯定了咱們所訪問的服務端是可信的；
6. 客戶端使用證書中的公鑰，繼續完成TLS的握手過程。

那麼，客戶端是是如何驗證某個證書的有效性，或者驗證策略是怎樣的?

證書頒發者通常提供兩種方式來驗證證書的有效性： CRL 和 OCSP。

CRL

CRL（Certificate Revocation List）即 證書撤銷名單。證書頒發者會提供一份已經失效證書的名單，供瀏覽器驗證證書使用。固然這份名單是巨長無比的，瀏覽器不可能每次TLS都去下載，因此經常使用的作法是瀏覽器會緩存這份名單，按期作後臺更新。這樣雖而後臺更新存在時間間隔，證書失效不實時，但通常也OK。

OCSP

OCSP(Online Certificate StatusProtocol)即 在線證書狀態協議。除了離線文件，證書頒發者也會提供實時的查詢接口，查詢某個特定證書目前是否有效。實時查詢的問題在於瀏覽器須要等待這個查詢結束才能繼續TLS握手，延遲會更大。

以上是站點在證書頒發者的角度說明會提供的兩種判斷方式，實際狀況下瀏覽器究竟會選擇哪一種方式判斷，每一個瀏覽器都會有本身的實現。下面是經過Chrome查看GitHub網站的證書信息：

到這裏差很少了，有什麼不對的地方，歡迎你們留言指出，一塊兒學習進步！

筆者不才，有些地方仍是理解不到位，如有不正之處，還請耐心指出，輕噴~。

參看文章

• TLS如何保證安全
• 圖解HTTPS協議加密解密全過程