背景：
非對稱加密：
基於數學方法，生成一個公鑰-密鑰對，來對數據做加密-解密，被公鑰加密的數據只能被私鑰解密，
同樣，被私鑰加密的數據也只能被公鑰解密。所以可以用別人公開的公鑰加密一段信息然後發送出去，
只有擁有對應密鑰的那個人才能解密。但是缺點是加密-解密的計算成本高，比較佔用cpu資源
對稱加密：
和非對稱加密相比，只生成一個密鑰，加密-解密都用這個密鑰，所以需要通信雙方都擁有該密鑰才能正常加/解密，優點是計算成本低，加/解密速度比非對稱加密快很多
HTTPS：
HTTP+SSL/TLS，本質上就是將原本由HTTP發送的明文通信內容，通過加密後發送，從而保證通信安全
CA：
全稱：certification authority ，證書頒發機構。是權威、可信的機構，可以視作是HTTPS可靠性的基石
HTTPS連接建立過程：
* 客戶端先預置CA的公鑰(CA-pub.key)，一般會是各瀏覽器自帶，用戶不關心
* 服務器生成公鑰(SRV-pub.key)，並將公鑰和各種信息(公司、地址、國家、郵箱等)發送給CA做認證，CA認證通過之後會用CA自己的私鑰(CA-pri.key)加密這些信息以及證書的hash值(hash-A)，生成完整證書，返回給服務器，服務器自行保存。
* 客戶端向服務端發起連接請求(ClientHello)，包含各種參數，這裏有一個客戶端生成的隨機數，我們把它叫做R1，後面會用到
* 服務端返回響應(ServerHello/Certificate/ServerKeyExchange/ServerHelloDone)，包含證書、服務端生成的隨機數R2、服務端選擇的加密算法、加密通信協議版本
* 客戶端拿到證書，用自身預置的CA公鑰(CA-pub.key)解開，得到對應的信息，將解開後得到的服務器信息做hash後得到hash-B，然後與解開證書後得到的hash-A進行對比，對比一致後則確認該證書未經篡改，就從證書中取得服務器的公鑰(SRV-pub.key)，並記錄下服務端生成的隨機數R2、以及服務端所選擇的加密方式
* 客戶端產生第三個隨機數R3(預主密碼)，此時客戶端擁有了三個隨機數R1/R2/R3，然後通過商定的加密方法使用R1/R2/R3生成對稱密鑰，然後將R3以及將握手消息hash後得到的hash值(verify_data1)通過服務端公鑰加密，加密後的內容發送給服務端(ClientKeyExchange/ChangeCipherSpec/ClientFinished)
* 服務端使用自身的私鑰進行解密，得到預主密碼R3，此時，服務端也擁有了R1/R2/R3，以及和客戶端商定好的加密方法，於是使用商定好的加密方法和這三個隨機數，生成對稱密鑰
* 服務端將握手消息做hash得到verify_data2，和客戶端發來的verify_data1做對比，如果一致，則認爲握手過程沒有被篡改，然後通過生成的對稱密鑰加密verify_data2，返回給客戶端(ServerFinished)
* 客戶端收到服務端返回的消息，使用對稱密鑰解密後得到verify_data2並和自身計算出的verify_data1做對比，如果一致，則認爲握手過程沒有被篡改，至此，密鑰交換成功
* 雙方使用對稱密鑰對通信內容進行加密，開始通信
建立連接的細節：
對服務器身份驗證的完整握手過程（包信息）
1、ClientHello
客戶端發起請求到服務器，其中包含了自身支持哪些加密方式和功能
其中包含：
1. Version：客戶端支持的最佳協議版本
2. Randon：隨機數，32字節的數據，其中28字節爲隨機生成，剩餘4字節包含額外信息，受
客戶端時鐘的影響；在握手時，客戶端和服務器都會提供隨機數，可以防止重放攻擊，並
確認初始數據交換的完整性
3. Session ID：首次會話時，該字段爲空。這個字段表示會話的唯一標識，服務器可以藉助它
從自己的緩存中找到對應的會話狀態，可以用於恢復會話
4. Cipher Suites：密碼套件，這是由客戶端支持的所有密碼套件組成的列表，按照優先級排列
5. Compression：客戶端可以提供多個自身支持的壓縮方法，默認爲null，代表沒有壓縮
6. Extensions：擴展
2、ServerHello
服務器將自身選擇的連接參數回傳給客戶端，這個消息的結構和1中類似，但每個字段只包含一個值；
服務器無需支持客戶端支持的最佳版本，如果服務器不支持客戶端相同的版本，可以提供某個其他版本以期待客戶端能接受
3、Certificate
發送服務器的x509證書鏈，證書鏈指的是由根證書(也就是CA簽名後的那個證書)派生而成的一系列證書
4、ServerKeyExchange
根據選擇的密鑰交換方式，服務器發送生成主密鑰的額外信息
5、ServerHelloDone
服務器通知自己完成了協商過程，在此之後，服務器會等待客戶端發送消息
6、ClientKeyExchange
客戶端發送生成主密鑰所需的額外信息
7、ChangeCipherSpec
已取得用以生成對稱密鑰的足夠信息，已生成加密密鑰，並將切換到加密模式
8、Finished
雙方計算髮送和收到的握手消息的MAC併發送，這個消息包含verify_data字段，
它的值是握手過程中所有消息的散列值，以驗證握手消息沒有被第三方篡改
* 至此，對稱密鑰交換完畢，後續的應用數據傳輸都以此對稱密鑰加密後發送。從而實現安全
問題：
1、爲什麼要用三個隨機數來生成對稱密鑰？
因爲計算機所生成的隨機數其實是僞隨機數，通過統計學的方法是有規律可循的。
但是分別由服務端、客戶端生成共三個隨機數，其隨機性可以大大提高，基本可以視作是真隨機數。
2、爲什麼Finished消息要帶有verify_data字段？
主要是爲了驗證整個握手過程沒有被第三方所篡改，確認Client和Server之間是否有攻擊者
3、爲什麼不完全使用非對稱加密來做？
因爲非對稱加密的CPU消耗很大，而對稱加密的消耗要小得多。並且通過非對稱加密交換的對稱密鑰並不是永久的，
當攻擊者暴力破解後，本次使用的對稱密鑰早就失效了，所以安全性是很有保障的。
總結：
HTTPS本質上就是通過使用非對稱加密方式交換對稱密鑰，從而實現安全性。
HTTPS的可靠性由CA作爲基礎，客戶端和服務端之間通過對CA的信任從而建立信任關係，
但需要考慮的是CA可以不通過域名所有者的同意而直接簽發某域名的證書。所以爲了解決這種情況，我們會使用“釘扎”的方式解決這個問題，下一次會詳細介紹