https解決的問題
因?yàn)樵诰W(wǎng)絡(luò)傳輸中，http是使用明文傳輸?shù)模苋菀妆蝗私俪只蛘叽鄹臄?shù)據(jù)尝江。為了能讓消息能在網(wǎng)絡(luò)中放心的傳輸，在http層之下加入安全套接字層SSL英上，這就是https.
HTTPS協(xié)議的主要作用可以分為兩種：
- 建立一個(gè)信息安全通道炭序，來保證數(shù)據(jù)傳輸?shù)陌踩?/li>
- 確認(rèn)網(wǎng)站的真實(shí)性啤覆。
那么https是如何對(duì)信息做加密的呢
- 傳輸過程中客戶端和服務(wù)端相互通信使用的是
對(duì)稱加密，因?yàn)閷?duì)稱加密比非對(duì)稱加密速度快 - 既然是對(duì)稱加密惭聂，那
a. 客戶端和服務(wù)端需要使用同一套公鑰
b. 連接到同一個(gè)服務(wù)端的多臺(tái)客戶端之間又不能使用同一套公鑰 - 那么問題就是如何在傳輸之前把加密用的公鑰給到客戶端和服務(wù)端
a. 服務(wù)端開發(fā)的時(shí)候窗声，需要向認(rèn)證中心CA獲取整數(shù)，也就是讓CA使用它的私鑰對(duì)服務(wù)端的公鑰進(jìn)行加密操作
b. 在客戶端發(fā)送握手的時(shí)候辜纲，服務(wù)端將證書發(fā)放給客戶端
c. 每個(gè)機(jī)器系統(tǒng)中都自帶一些公認(rèn)的CA的受信任證書笨觅，這些證書中含有可以解開對(duì)應(yīng)CA認(rèn)證過的服務(wù)端的證書--> 進(jìn)行服務(wù)端證書解密
d. 這個(gè)時(shí)候就可以得到握手過程中使用的非對(duì)稱加密的公鑰了
e. 拿到這個(gè)公鑰只是為了生成后續(xù)傳輸過程中的公鑰的第一步
f. 客戶端拿著上面的說的公鑰古话，服務(wù)端拿著自己的私鑰凯砍，兩邊進(jìn)行非對(duì)稱加密的傳輸，溝通生成后續(xù)傳輸使用的對(duì)稱加密的公鑰喻杈。
https握手的過程：
下面是別的網(wǎng)站上看到的扫俺，覺得寫得很好苍苞，直接拷貝過來了
client_hello，客戶端發(fā)起請(qǐng)求狼纬，以明文傳輸請(qǐng)求信息柒啤，包含版本信息，加密套件候選列表畸颅，壓縮算法候選列表担巩，隨機(jī)數(shù)，擴(kuò)展字段等信息没炒，相關(guān)信息如下：
支持的最高TSL協(xié)議版本version涛癌，從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，當(dāng)前基本不再使用低于 TLSv1 的版本;
客戶端支持的加密套件 cipher suites 列表送火， 每個(gè)加密套件對(duì)應(yīng)前面 TLS 原理中的四個(gè)功能的組合：認(rèn)證算法 Au (身份驗(yàn)證)拳话、密鑰交換算法 KeyExchange(密鑰協(xié)商)、對(duì)稱加密算法 Enc (信息加密)和信息摘要 Mac(完整性校驗(yàn));
支持的壓縮算法 compression methods 列表种吸，用于后續(xù)的信息壓縮傳輸;
隨機(jī)數(shù) random_C弃衍，用于后續(xù)的密鑰的生成;
擴(kuò)展字段 extensions，支持協(xié)議與算法的相關(guān)參數(shù)以及其它輔助信息等坚俗，常見的 SNI 就屬于擴(kuò)展字段镜盯，后續(xù)單獨(dú)討論該字段作用。server_hello+server_certificate+sever_hello_done
a. server_hello, 服務(wù)端返回協(xié)商的信息結(jié)果猖败，包括選擇使用的協(xié)議版本 version速缆，選擇的加密套件 cipher suite，選擇的壓縮算法 compression method恩闻、隨機(jī)數(shù) random_S 等艺糜，其中隨機(jī)數(shù)用于后續(xù)的密鑰協(xié)商;
b. server_certificates, 服務(wù)器端配置對(duì)應(yīng)的證書鏈，用于身份驗(yàn)證與密鑰交換;
c. server_hello_done，通知客戶端 server_hello 信息發(fā)送結(jié)束;證書校驗(yàn)
客戶端驗(yàn)證證書的合法性破停，如果驗(yàn)證通過才會(huì)進(jìn)行后續(xù)通信翅楼，否則根據(jù)錯(cuò)誤情況不同做出提示和操作，合法性驗(yàn)證包括如下：
證書鏈的可信性 trusted certificate path真慢，方法如前文所述;
證書是否吊銷 revocation犁嗅，有兩類方式離線 CRL 與在線 OCSP，不同的客戶端行為會(huì)不同;
有效期 expiry date晤碘，證書是否在有效時(shí)間范圍;
域名 domain褂微，核查證書域名是否與當(dāng)前的訪問域名匹配，匹配規(guī)則后續(xù)分析;client_key_exchange+change_cipher_spec+encrypted_handshake_message
a. client_key_exchange园爷，合法性驗(yàn)證通過之后宠蚂，客戶端計(jì)算產(chǎn)生隨機(jī)數(shù)字 Pre-master，并用證書公鑰加密童社，發(fā)送給服務(wù)器;
b. 此時(shí)客戶端已經(jīng)獲取全部的計(jì)算協(xié)商密鑰需要的信息：兩個(gè)明文隨機(jī)數(shù) random_C 和 random_S 與自己計(jì)算產(chǎn)生的 Pre-master求厕，計(jì)算得到協(xié)商密鑰;
enc_key=Fuc(random_C, random_S, Pre-Master)
c. change_cipher_spec，客戶端通知服務(wù)器后續(xù)的通信都采用協(xié)商的通信密鑰和加密算法進(jìn)行加密通信;
d. encrypted_handshake_message扰楼，結(jié)合之前所有通信參數(shù)的 hash 值與其它相關(guān)信息生成一段數(shù)據(jù)呀癣，采用協(xié)商密鑰 session secret 與算法進(jìn)行加密，然后發(fā)送給服務(wù)器用于數(shù)據(jù)與握手驗(yàn)證;change_cipher_spec+encrypted_handshake_message
a. 服務(wù)器用私鑰解密加密的 Pre-master 數(shù)據(jù)弦赖，基于之前交換的兩個(gè)明文隨機(jī)數(shù) random_C 和 random_S项栏，計(jì)算得到協(xié)商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master);
b. 計(jì)算之前所有接收信息的 hash 值，然后解密客戶端發(fā)送的 encrypted_handshake_message蹬竖，驗(yàn)證數(shù)據(jù)和密鑰正確性;
c. change_cipher_spec, 驗(yàn)證通過之后沼沈，服務(wù)器同樣發(fā)送 change_cipher_spec 以告知客戶端后續(xù)的通信都采用協(xié)商的密鑰與算法進(jìn)行加密通信;
d. encrypted_handshake_message, 服務(wù)器也結(jié)合所有當(dāng)前的通信參數(shù)信息生成一段數(shù)據(jù)并采用協(xié)商密鑰 session secret 與算法加密并發(fā)送到客戶端;握手結(jié)束
客戶端計(jì)算所有接收信息的 hash 值，并采用協(xié)商密鑰解密 encrypted_handshake_message币厕，驗(yàn)證服務(wù)器發(fā)送的數(shù)據(jù)和密鑰列另，驗(yàn)證通過則握手完成;加密通信
開始使用協(xié)商密鑰與算法進(jìn)行加密通信。
