概述
HTTPS，從字面上看，即在HTTP協(xié)議下加上一層SSL(安全套接字層 secure socket layer)，對(duì)于上層應(yīng)用來看，原來的發(fā)送接收數(shù)據(jù)的流程不變，這便很好的兼容了HTTP協(xié)議。
一、協(xié)議的加密流程
我們知道，非對(duì)稱加密是相較于對(duì)稱加密更為安全的一種加密方式，但是非對(duì)稱加密所需要耗費(fèi)的計(jì)算資源也會(huì)隨之提高許多。所以https協(xié)議的基本原理就是，通過SSL/TLS握手安全的協(xié)商出一份對(duì)稱加密的密鑰，隨后傳輸?shù)臄?shù)據(jù)都采用該密鑰進(jìn)行加解密。
1.1、SSL/TLS握手過程
1. Client Hello
握手第一步是客戶端向服務(wù)端發(fā)送 Client Hello 消息，這個(gè)消息里包含了一個(gè)客戶端生成的隨機(jī)數(shù) Random1、客戶端支持的加密套件（Support Ciphers）和 SSL Version 等信息。
2. Server Hello
第二步是服務(wù)端向客戶端發(fā)送 Server Hello 消息，這個(gè)消息會(huì)從 Client Hello 傳過來的 Support Ciphers 里確定一份加密套件，這個(gè)套件決定了后續(xù)加密和生成摘要時(shí)具體使用哪些算法，另外還會(huì)生成一份隨機(jī)數(shù) Random2。注意，至此客戶端和服務(wù)端都擁有了兩個(gè)隨機(jī)數(shù)（Random1+ Random2），這兩個(gè)隨機(jī)數(shù)會(huì)在后續(xù)生成對(duì)稱秘鑰時(shí)用到。
客戶端驗(yàn)證
這一步是服務(wù)端將自己的證書下發(fā)給客戶端，讓客戶端驗(yàn)證自己的身份，客戶端驗(yàn)證通過后取出證書中的公鑰。
3. Certificate Verify
客戶端收到服務(wù)端傳來的證書后，先從 CA 驗(yàn)證該證書的合法性，驗(yàn)證通過后取出證書中的服務(wù)端公鑰，再生成一個(gè)隨機(jī)數(shù) Random3，再用服務(wù)端公鑰非對(duì)稱加密 Random3 生成 PreMaster Key。
上面客戶端根據(jù)服務(wù)器傳來的公鑰生成了 PreMaster Key，Client Key Exchange 就是將這個(gè) key 傳給服務(wù)端，服務(wù)端再用自己的私鑰解出這個(gè) PreMaster Key 得到客戶端生成的 Random3。至此，客戶端和服務(wù)端都擁有 Random1 + Random2 + Random3，兩邊再根據(jù)同樣的算法就可以生成一份秘鑰，握手結(jié)束后的應(yīng)用層數(shù)據(jù)都是使用這個(gè)秘鑰進(jìn)行對(duì)稱加密。為什么要使用三個(gè)隨機(jī)數(shù)呢？這是因?yàn)?SSL/TLS 握手過程的數(shù)據(jù)都是明文傳輸?shù)模⑶叶鄠€(gè)隨機(jī)數(shù)種子來生成秘鑰不容易被暴力破解出來。
4. 密鑰協(xié)商驗(yàn)證
服務(wù)器收到客戶端的第三個(gè)隨機(jī)數(shù)pre-master key之后，計(jì)算生成本次會(huì)話所用的"會(huì)話密鑰"。然后，向客戶端最后發(fā)送下面信息。
（1）編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
（2）服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來供客戶端校驗(yàn)。
至此，整個(gè)握手階段全部結(jié)束。接下來，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的HTTP協(xié)議，只不過用"會(huì)話密鑰"加密內(nèi)容。
總結(jié)
https的傳輸過程，前期密鑰的協(xié)商通過非對(duì)稱加密實(shí)現(xiàn)，后期數(shù)據(jù)的加密使用的是對(duì)稱加密。(密鑰由非對(duì)稱加密協(xié)商得到)
