https

HTTP 一般是明文傳輸，很容易被攻擊者竊取重要信息。所以誕生了HTTPS。

HTTPS 的全稱為 （Hyper Text Transfer Protocol over SecureSocket Layer），全稱有點(diǎn)長，HTTPS 和 HTTP 有很大的不同在于 HTTPS 是以安全為目標(biāo)的 HTTP 通道，在 HTTP 的基礎(chǔ)上通過傳輸加密和身份認(rèn)證保證了傳輸過程的安全性。

HTTPS 在 HTTP 的基礎(chǔ)上增加了 SSL 層，也就是說 HTTPS = HTTP + SSL。

HTTPS工作在443端口，而HTTP默認(rèn)工作在80端口。

SSL 是“Secure Sockets Layer”的縮寫，中文叫做“安全套接層”。它是在上世紀(jì)90年代中期，由網(wǎng)景公司設(shè)計的。到了1999年，SSL 應(yīng)用廣泛，已經(jīng)成為互聯(lián)網(wǎng)上的事實(shí)標(biāo)準(zhǔn)。IETF 就把SSL 標(biāo)準(zhǔn)化。標(biāo)準(zhǔn)化之后SSL被改為 TLS（Transport Layer Security傳輸層安全協(xié)議）。SSL/ TLS

SSL原理詳解

SSL協(xié)議結(jié)構(gòu)：

SSL協(xié)議分為兩層，下層為SSL記錄協(xié)議，上層為SSL握手協(xié)議、SSL密碼變化協(xié)議和SSL警告協(xié)議。

1.下層為SSL記錄協(xié)議，主要作用是為高層協(xié)議提供基本的安全服務(wù)

建立在可靠的傳輸之上，負(fù)責(zé)對上層的數(shù)據(jù)進(jìn)行分塊、壓縮、計算并添加MAC（消息驗(yàn)證碼） 、加密，最后把記錄塊傳輸給對方。

2.上層為SSL握手協(xié)議、SSL密碼變化協(xié)議和SSL報警協(xié)議

1> SSL握手協(xié)議：SSL握手協(xié)議被封裝在SSL記錄協(xié)議中，該協(xié)議允許服務(wù)器與客戶端在應(yīng)用程序傳輸和接收數(shù)據(jù)之前互相認(rèn)證、協(xié)商加密算法和密鑰。在初次建立SSL連接時，服務(wù)器與客戶機(jī)交換一系列消息。

2> SSL修改密文協(xié)議：保障SSL傳輸過程中的安全性，客戶端和服務(wù)器雙方應(yīng)該每隔一段時間改變加密規(guī)范

3> SSL報警協(xié)議：用來為對等體傳遞SSL的相關(guān)警告。如果在通信過程中某一方發(fā)現(xiàn)任何異常，就需要給對方發(fā)送一條警示消息通告。

SSL工作大致可以分為兩個階段

1.第一階段：Handshake phase（握手階段）

• 協(xié)商加密算法

• 認(rèn)證服務(wù)器

• 建立用于加密和MAC（Message Authentication Code）的會話密鑰

2.第二階段：Secure data transfer phase（安全數(shù)據(jù)傳輸階段）

• 在已經(jīng)建立的SSL數(shù)據(jù)通道里安全的傳輸數(shù)據(jù)

SSL協(xié)議提供的服務(wù)：

1）認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的 客戶機(jī)和服務(wù)器
2）加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊取
3）維護(hù)數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過程中不被改變。
當(dāng)你在瀏覽器的地址欄上輸入https開頭的網(wǎng)址后，瀏覽器和服務(wù)器之間會在接下來的幾百毫秒內(nèi)進(jìn)行大量的通信：

認(rèn)證服務(wù)器：瀏覽器內(nèi)置一個受信任的CA機(jī)構(gòu)列表，并保存了這些CA機(jī)構(gòu)的證書。第一階段服務(wù)器會提供經(jīng)CA機(jī)構(gòu)認(rèn)證頒發(fā)的服務(wù)器證書，如果認(rèn)證該服務(wù)器證書的CA機(jī)構(gòu)，存在于瀏覽器的受信任CA機(jī)構(gòu)列表中，并且服務(wù)器證書中的信息與當(dāng)前正在訪問的網(wǎng)站（域名等）一致，那么瀏覽器就認(rèn)為服務(wù)端是可信的，并從服務(wù)器證書中取得服務(wù)器公鑰，用于后續(xù)流程。否則，瀏覽器將提示用戶，根據(jù)用戶的選擇，決定是否繼續(xù)。當(dāng)然，我們可以管理這個受信任CA機(jī)構(gòu)列表，添加我們想要信任的CA機(jī)構(gòu)，或者移除我們不信任的CA機(jī)構(gòu)。

SSL原理

在用SSL進(jìn)行通信之前，首先要使用SSL的Handshake協(xié)議在通信兩端握手，協(xié)商數(shù)據(jù)傳輸中要用到的相關(guān)安全參數(shù)（如加密算法、共享密鑰、產(chǎn)生密鑰所要的材料等），并對對端的身份進(jìn)行驗(yàn)證。

SSL第一階段

客戶端首先發(fā)送ClientHello消息到服務(wù)端，服務(wù)端收到ClientHello消息后，再發(fā)送ServerHello消息回應(yīng)客戶端。

ClientHello

客戶端瀏覽器向服務(wù)器端發(fā)送如下信息：

• Version 版本號（客戶端支持的SSL /TLS協(xié)議的版本號。）

• Random 客戶端產(chǎn)生的#隨機(jī)數(shù)#

• Session id 會話ID

• Cipher Suite（密鑰算法套件）：加密套件里面包含三部分：

• 
  

• 1、加密算法；

• 
  

• 2、完整性校驗(yàn)算法（MD5，哈希算法）；

• 3：密鑰協(xié)商算法；主要看客戶端和服務(wù)端支持哪一個算法，客戶端會把自己支持的加密算法發(fā)送給服務(wù)端。

• Compression Methods（壓縮算法）

• 預(yù)留

ServerHello

服務(wù)器端向客戶端發(fā)送如下信息：

• 服務(wù)器把自己支持的版本列出來，然后和客戶端進(jìn)行比較，拿出客戶端支持的最新版本

• 服務(wù)器端產(chǎn)生#隨機(jī)數(shù)#

• 服務(wù)端也列出加密套件，協(xié)商后使用統(tǒng)一的 加密套件

• 客戶端產(chǎn)生的會話ID寫進(jìn)服務(wù)器里面

• 如果支持客戶端的壓縮算法，則使用

• 擴(kuò)展包

在此階段之后通信雙方分別確定了：

1、SSL的版本；2、加密套件；3、壓縮算法；4、倆個隨機(jī)數(shù)

SSL第二階段

服務(wù)器向客戶端發(fā)送消息，本階段服務(wù)器是唯一發(fā)送方，客戶端是唯一接收方。

本階段共有四個消息，如下：

1. 證書：服務(wù)器將數(shù)字證書和到根CA整個鏈發(fā)給客戶端，使客戶端能用服務(wù)器證書中的服務(wù)器公鑰認(rèn)證服務(wù)器。

2. 服務(wù)器密鑰交換（可選）：這里視密鑰交換算法而定。

3. 證書請求：服務(wù)端可能會要求客戶自身進(jìn)行驗(yàn)證。

4. 服務(wù)器握手完成：第二階段的結(jié)束，第三階段開始的信號

Certificate（可選）——第一次建立必須要有證書

一般情況下，除了會話恢復(fù)時不需要發(fā)送該消息，在SSL握手的全過程中都需要該消息。消息中包含一個X.509證書，證書中包含公鑰，發(fā)給客戶端用來驗(yàn)證簽名或者在密鑰交換時給消息加密。
這一步是服務(wù)端將自己的證書下發(fā)給客戶端，讓客戶端驗(yàn)證自己的身份，客戶端驗(yàn)證通過后取出證書中的公鑰，以便后面的使用。

Server Key Exchange（可選）

根據(jù)之前的client hello消息中的cipther suite信息決定了，密鑰交換的方法（例如RSA和DH），因此在此消息中便會完成密鑰交換所需的一系列參數(shù)。

Certificate Request（可選）——可以是單向身份認(rèn)證，也可以是雙向

這一步是可選的，在安全性要求高的場合可以看到；服務(wù)端發(fā)送Certificate Request消息，請求客戶端發(fā)送他自己的證書來進(jìn)行驗(yàn)證。該消息中包含服務(wù)器端支持的證書類型（RSA、DSA、ECDSA），和服務(wù)器所信任的所有證書的發(fā)行機(jī)構(gòu)的CA列表，客戶端會用這些信息來篩選證書。

ServerHello Done

表示服務(wù)器已將所有的信息發(fā)送完畢，等待客戶端發(fā)送消息

SSL第三階段

客戶端收到服務(wù)器發(fā)送的一系列消息并解析后，將本端相應(yīng)的消息發(fā)送給服務(wù)器。

客戶機(jī)啟動SSL握手第3階段，是本階段所有消息的唯一發(fā)送方，服務(wù)器是所有消息的唯一接收方。該階段分為3步：

1. 證書（可選）：為了對服務(wù)器證明自身，客戶要發(fā)送一個證書信息，這是可選的，在IIS中可以配置強(qiáng)制客戶端證書認(rèn)證。

2. 客戶機(jī)密鑰交換（Pre-master-secret）：這里客戶端將預(yù)備主密鑰發(fā)送給服務(wù)端，注意這里會使用服務(wù)端的公鑰進(jìn)行加密。

3. 證書驗(yàn)證（可選）：對從第一條消息以來的所有握手消息進(jìn)行簽名。

Certificate（可選）

如果在第二階段服務(wù)器要求客戶端發(fā)送證書，客戶端便會發(fā)送自己的證書，服務(wù)器端之前在發(fā)送的Certificate Request消息中包含了服務(wù)器所支持的證書類型和CA列表，客戶端會在證書中找到滿足要求的一個發(fā)送給服務(wù)器。若客戶端沒有證書，則會發(fā)送一個no_certificate警告。

Client Key Exchange

• 根據(jù)之前從服務(wù)端收到的隨機(jī)數(shù)，按照不同的密鑰交換算法，算出一個Pre-master，發(fā)送給服務(wù)器，服務(wù)器收到pre-master,算出一個main-master。而客戶端也能通過Pre-master自己算出一個main-master。如此一來，雙方就算出了對稱密鑰。

• 如果是RSA算法，會生成一個48位的隨機(jī)數(shù)，然后用server的公鑰加密后放入報文中；如果是DH算法，發(fā)送的就是客戶端的DH參數(shù)，之后客戶端和服務(wù)端根據(jù)DH算法，計算出相同的Pre-master secret。

• 本消息在發(fā)送過程中，使用了服務(wù)器的公鑰加密，服務(wù)器在收到后需要用服務(wù)器的私鑰解密才能得到Pre-master Key。

Certificate Verify（可選）

只有在客戶端在發(fā)送了證書到服務(wù)端時，這個消息才需要發(fā)送，其中包含簽名，對從握手第一條消息以來的所有握手消息的HMAC值（用master_secret）進(jìn)行簽名。

SSL第四階段

完成握手協(xié)議，建立SSL連接。

該階段有四個消息交互，前兩個為客戶端發(fā)送，后兩個為服務(wù)器發(fā)送。

建立起一個安全的連接，客戶端發(fā)送一個Change Cipher spec消息，并且把協(xié)商得到的Cipher suite拷貝到當(dāng)前連接的狀態(tài)之中。然后客戶端使用新的算法和密鑰參數(shù)發(fā)送一個Finished消息，這條消息可以檢測密鑰交換和認(rèn)證過程是否已經(jīng)成功，其中包括一個校驗(yàn)值，對客戶端整個握手消息進(jìn)行校驗(yàn)。服務(wù)器同樣發(fā)送一個Change Cipher Spec消息和Finished消息。握手過程完成，客戶端和服務(wù)器可以交換應(yīng)用層數(shù)據(jù)進(jìn)行通信。

Change Cipher Spec

編碼改變通知，表示隨后的信息將用雙方商定的加密算法和和密鑰發(fā)送（ChangeCipherSpec是一個獨(dú)立的協(xié)議，體現(xiàn)在數(shù)據(jù)包中就是一個字節(jié)的數(shù)據(jù)，用于告知服務(wù)端，客戶端已經(jīng)切換到之前協(xié)商好的加密套件（Cipher Suite）的狀態(tài)，準(zhǔn)備使用之前協(xié)商好的加密套件加密數(shù)據(jù)并傳輸了）。

Client finished

客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時也是前面所有發(fā)送的內(nèi)容的hash值，用來供服務(wù)器校驗(yàn)。（使用HMAC算法計算收到和發(fā)送的所有握手消息的摘要，加密后發(fā)送。此數(shù)據(jù)是為了在正式傳輸應(yīng)用數(shù)據(jù)之前對剛剛握手建立起來的加解密通道進(jìn)行驗(yàn)證。）

Server Finished

服務(wù)端握手結(jié)束通知。

使用私鑰解密加密的Pre-master數(shù)據(jù)，基于之前(Client Hello 和 Server Hello)交換的兩個明文隨機(jī)數(shù) random_C 和 random_S，計算得到協(xié)商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master);
計算之前所有接收信息的hash值，然后解密客戶端發(fā)送的 encrypted_handshake_message，驗(yàn)證數(shù)據(jù)和密鑰正確性;
發(fā)送一個Change Cipher Spec（告知客戶端已經(jīng)切換到協(xié)商過的加密套件狀態(tài)，準(zhǔn)備使用加密套件和 Session Secret加密數(shù)據(jù)了）
服務(wù)端也會使用Session Secret加密一段Finish消息發(fā)送給客戶端，以驗(yàn)證之前通過握手建立起來的加解密通道是否成功。
根據(jù)之前的握手信息，如果客戶端和服務(wù)端都能對Finish信息進(jìn)行正常加解密且消息正確的被驗(yàn)證，則說明握手通道已經(jīng)建立成功，接下來，雙方可以使用上面產(chǎn)生的Session Secret對數(shù)據(jù)進(jìn)行加密傳輸了。

SSL原理—會話恢復(fù)

會話恢復(fù)是指只要客戶端和服務(wù)器已經(jīng)通信過一次，它們就可以通過會話恢復(fù)的方式來跳過整個握手階段而直接進(jìn)行數(shù)據(jù)傳輸。SSL采用會話恢復(fù)的方式來減少SSL握手過程中造成的巨大開銷。此功能從之前的13步減少到6步，大大減少了開銷。

兩種會話機(jī)制

• 會話標(biāo)識 session ID: 由服務(wù)器端支持，協(xié)議中的標(biāo)準(zhǔn)字段，因此基本所有服務(wù)器都支持，服務(wù)器端保存會話ID以及協(xié)商的通信信息，Nginx 中1M 內(nèi)存約可以保存4000個 session ID 機(jī)器相關(guān)信息，占用服務(wù)器資源較多;

• 會話記錄 session ticket :需要服務(wù)器和客戶端都支持，屬于一個擴(kuò)展字段，支持范圍約60%(無可靠統(tǒng)計與來源)，將協(xié)商的通信信息加密之后發(fā)送給客戶端保存，密鑰只有服務(wù)器知道，占用服務(wù)器資源很少。

二者對比，主要是保存協(xié)商信息的位置與方式不同，類似與 http 中的 session 與 cookie。二者都存在的情況下，(nginx 實(shí)現(xiàn))優(yōu)先使用 session_ticket。

恢復(fù)過程
如果服務(wù)器和客戶端之間曾經(jīng)建立過連接，服務(wù)器會在握手成功后返回一個session ID，并保存對應(yīng)的參數(shù)在服務(wù)器中。如果客戶端和服務(wù)器需要再次連接，則需要在Client hello消息中攜帶記錄的信息，返回給服務(wù)器。服務(wù)器根據(jù)收的到的Session ID檢索緩存記錄，如果有緩存，則返回一個Change Cipher Spec消息和Finished消息，如果沒有緩存則正常進(jìn)行握手。如果客戶端能夠驗(yàn)證通過服務(wù)器加密數(shù)據(jù)，則同樣回復(fù)一個Change Cipher Spec消息和Finished消息。服務(wù)器驗(yàn)證通過則握手建立成功，開始進(jìn)行正常的加密數(shù)據(jù)通信。

SSL記錄協(xié)議

SSL記錄協(xié)議主要用于實(shí)現(xiàn)對數(shù)據(jù)的分塊、加密解密、壓縮解壓縮、完整性檢測和封裝各種高層協(xié)議。

主要包括：

• 內(nèi)容類型

• 協(xié)議版本號

• 記錄數(shù)據(jù)的長度

• 數(shù)據(jù)有效載荷

• 散列算法計算消息認(rèn)證代碼

1. 將上層分下來的數(shù)據(jù)包分成合適的數(shù)據(jù)塊，但是每個數(shù)據(jù)塊不得超過214字節(jié)。

2. 對每個數(shù)據(jù)塊進(jìn)行壓縮，但是不能丟失數(shù)據(jù)信息。

3. 計算壓縮后的數(shù)據(jù)消息認(rèn)證碼MAC，并添加在壓縮包后。添加后總長度不得超過2262字節(jié)。

4. 對稱密碼加密。

5. 給SSL添加一個首部。其中包括:內(nèi)容類型、主要版本、次要版本、壓縮長度等信息。通過以上過程把原始的數(shù)據(jù)加密為SSL協(xié)議的記錄集。

參考：https://blog.csdn.net/weixin_43997530/article/details/108048388