一、背景
現(xiàn)在大多數(shù)的網(wǎng)站都升級為https協(xié)議了，包括百度、知乎等，當然還包括對安全性要求高的支付業(yè)務和銀行業(yè)務都是用https。https相對于http的劣勢是，https建立連接需要多次握手，而且還要進行RSA加密解密，這是個耗時的過程，那么為什么對安全性要求不高的網(wǎng)站也升級為https。那是因為http是用明文傳輸，在傳輸過程中，我們的信息可能會被篡改，或者會被第三方截取插入一些別的信息，比如說廣告植入，這嚴重影響了用戶體驗。
既然要升級為https協(xié)議，那就很有必要知道https的原理是什么，https是怎么保證信息只有通信雙方能解析而不被第三方截獲導致信息被竊取、篡改。
二、https驗證原理
2.1 原理圖
下面是一張https建立連接的原理圖，下面會對每一步進行說明。
2.2 https建立連接過程
2.2.1 客戶端訪問https連接
這一步，就是相當于我們在瀏覽器上輸入url回車的過程。這個時候瀏覽器或者客戶端（接下來統(tǒng)一為客戶端）會把我們客戶端支持的加密算法Cipher Suite（密鑰算法套件）帶給服務端。
2.2.2 - 2.2.3 服務端發(fā)送證書（公鑰）給客戶端
服務端接收Cipher后，和自己支持的加密算法進行比對，如果不符合，則斷開連接。否則，服務端會把符合的算法和證書發(fā)給客戶端，包括證書時間、證書日期、證書頒發(fā)的機構(gòu)。
2.2.4- 2.2.5 客戶端驗證服務端的證書
1、客戶端驗證證書，包括頒發(fā)證書的機構(gòu)是否合法與是否過期，證書中包含的網(wǎng)站地址是否與正在訪問的地址一致等
2、驗證通過后（或者用戶接受了不信任的證書），客戶端會生成一個隨機字符串，然后用服務端的公鑰進行加密。這里就保證了只有服務端才能看到這串隨機字符串（因為服務端擁有公鑰對應的私鑰，RSA解密，可以知道客戶端的隨機字符串）。
3、生成握手信息 用約定好的HASH算法，對握手信息進行取HASH，然后用隨機字符串加密握手信息和握手信息的簽名HASH值，把結(jié)果發(fā)給服務端。這里之所以要帶上握手信息的HASH是因為，防止信息被篡改。如果信息被篡改，那么服務端接收到信息進行HASH時，就會發(fā)現(xiàn)HASH值和客戶端傳回來的不一樣。這里就保證了信息不會被篡改。
2.2.6 - 2.2.7 服務端接收加密信息，解密得到客戶端提供的隨機字符串
服務端接收到加密信息后，首先用私鑰解密得到隨機字符串。然后用隨機字符串解密握手信息，獲得握手信息和握手信息的HASH值，服務端對握手信息進行HASH，比對客戶端傳回來的HASH。如果相同，則說明信息沒有被篡改。
服務端驗證完客戶端的信息以后，同樣使用隨機字符串加密握手信息和握手信息的HASH值發(fā)給客戶端。
2.2.8 客戶端驗證服務端返回的握手信息，完成握手
客戶端接收到服務端發(fā)回來的握手信息后，用一開始生成的隨機字符串對密文進行解密，得到握手信息和握手信息的HASH值，像一步服務端驗證一樣對握手信息進行校驗，校驗通過后，握手完畢。從這里開始，客戶端和服務端的通信就使用那串隨機字符串進行AES對稱加密通信。
2.3 驗證總結(jié)
使用RSA非對稱算法，服務端向客戶端發(fā)送公鑰，公鑰包含了域名、頒發(fā)機構(gòu)、過期日期。保證了公鑰的合法性和服務端的身份正確性（而不會被黑客冒充）
客戶端向第三方驗證公鑰的合法性，驗證通過后向服務端約定對稱加密的隨機字符號。保證了隨機字符串只有通信雙方知道。
接下來的通信就使用這個隨機字符號進行加密通信。因為隨機字符串只有雙方知道，所以信息不會被截獲。
三、客戶端驗證證書的合法性
為了驗證證書的合法性，首先客戶端要知道一些合法的證書機構(gòu)，這就是我們所說的根證書。而根證書會保存在用戶的瀏覽器或者其它客戶端，像jdk的根證書列表。
當然證書不可能只有幾個機構(gòu)進行頒發(fā)的，所以證書的頒發(fā)是一級一級的。客戶端在驗證證書也是一級一級往下驗證。下面是阿里的證書：
最頂級的VeriSign Class 3 Public Primary Certification Authori... 就是根證書了， 這個證書一般會保存在客戶端，在客戶端安裝時就有一組根證書了，如果服務端根證書在客戶端的信任列表中，那么就會向根證書驗證二級證書的合法性，然后再向二級證書機構(gòu)驗證三級證書的合法性，以此類推。
