概述

HTTPS，從字面上看，即在HTTP協(xié)議下加上一層SSL(安全套接字層 secure socket layer)，對于上層應用來看，原來的發(fā)送接收數(shù)據(jù)的流程不變，這便很好的兼容了HTTP協(xié)議。

一、協(xié)議的加密流程

我們知道，非對稱加密是相較于對稱加密更為安全的一種加密方式，但是非對稱加密所需要耗費的計算資源也會隨之提高許多。所以https協(xié)議的基本原理就是，通過SSL/TLS握手安全的協(xié)商出一份對稱加密的密鑰，隨后傳輸?shù)臄?shù)據(jù)都采用該密鑰進行加解密。

1.1、SSL/TLS握手過程

1. Client Hello

握手第一步是客戶端向服務端發(fā)送 Client Hello 消息，這個消息里包含了一個客戶端生成的隨機數(shù) Random1、客戶端支持的加密套件（Support Ciphers）和 SSL Version 等信息。

2. Server Hello

第二步是服務端向客戶端發(fā)送 Server Hello 消息，這個消息會從 Client Hello 傳過來的 Support Ciphers 里確定一份加密套件，這個套件決定了后續(xù)加密和生成摘要時具體使用哪些算法，另外還會生成一份隨機數(shù) Random2。注意，至此客戶端和服務端都擁有了兩個隨機數(shù)（Random1+ Random2），這兩個隨機數(shù)會在后續(xù)生成對稱秘鑰時用到。
客戶端驗證
這一步是服務端將自己的證書下發(fā)給客戶端，讓客戶端驗證自己的身份，客戶端驗證通過后取出證書中的公鑰。

3. Certificate Verify

客戶端收到服務端傳來的證書后，先從 CA 驗證該證書的合法性，驗證通過后取出證書中的服務端公鑰，再生成一個隨機數(shù) Random3，再用服務端公鑰非對稱加密 Random3 生成 PreMaster Key。

上面客戶端根據(jù)服務器傳來的公鑰生成了 PreMaster Key，Client Key Exchange 就是將這個 key 傳給服務端，服務端再用自己的私鑰解出這個 PreMaster Key 得到客戶端生成的 Random3。至此，客戶端和服務端都擁有 Random1 + Random2 + Random3，兩邊再根據(jù)同樣的算法就可以生成一份秘鑰，握手結(jié)束后的應用層數(shù)據(jù)都是使用這個秘鑰進行對稱加密。為什么要使用三個隨機數(shù)呢？這是因為 SSL/TLS 握手過程的數(shù)據(jù)都是明文傳輸?shù)?，并且多個隨機數(shù)種子來生成秘鑰不容易被暴力破解出來。

4. 密鑰協(xié)商驗證

服務器收到客戶端的第三個隨機數(shù)pre-master key之后，計算生成本次會話所用的"會話密鑰"。然后，向客戶端最后發(fā)送下面信息。

（1）編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。

（2）服務器握手結(jié)束通知，表示服務器的握手階段已經(jīng)結(jié)束。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值，用來供客戶端校驗。

至此，整個握手階段全部結(jié)束。接下來，客戶端與服務器進入加密通信，就完全是使用普通的HTTP協(xié)議，只不過用"會話密鑰"加密內(nèi)容。

總結(jié)

https的傳輸過程，前期密鑰的協(xié)商通過非對稱加密實現(xiàn)，后期數(shù)據(jù)的加密使用的是對稱加密。(密鑰由非對稱加密協(xié)商得到)