HTTP 一般是明文傳輸，很容易被攻擊者竊取重要信息。所以誕生了HTTPS。
HTTPS 的全稱(chēng)為 （Hyper Text Transfer Protocol over SecureSocket Layer），全稱(chēng)有點(diǎn)長(cháng)，HTTPS 和 HTTP 有很大的不同在于 HTTPS 是以安全為目標的 HTTP 通道，在 HTTP 的基礎上通過(guò)傳輸加密和身份認證保證了傳輸過(guò)程的安全性。
HTTPS 在 HTTP 的基礎上增加了 SSL 層，也就是說(shuō) HTTPS = HTTP + SSL。
HTTPS工作在443端口，而HTTP默認工作在80端口。
SSL 是“Secure Sockets Layer”的縮寫(xiě)，中文叫做“安全套接層”。它是在上世紀90年代中期，由網(wǎng)景公司設計的。到了1999年，SSL 應用廣泛，已經(jīng)成為互聯(lián)網(wǎng)上的事實(shí)標準。IETF 就把SSL 標準化。標準化之后SSL被改為 TLS（Transport Layer Security傳輸層安全協(xié)議）。SSL/ TLS
SSL協(xié)議分為兩層，下層為SSL記錄協(xié)議，上層為SSL握手協(xié)議、SSL密碼變化協(xié)議和SSL警告協(xié)議。
1.下層為SSL記錄協(xié)議，主要作用是為高層協(xié)議提供基本的安全服務(wù)
建立在可靠的傳輸之上，負責對上層的數據進(jìn)行分塊、壓縮、計算并添加MAC（消息驗證碼） 、加密，最后把記錄塊傳輸給對方。
2.上層為SSL握手協(xié)議、SSL密碼變化協(xié)議和SSL報警協(xié)議
1> SSL握手協(xié)議：SSL握手協(xié)議被封裝在SSL記錄協(xié)議中，該協(xié)議允許服務(wù)器與客戶(hù)端在應用程序傳輸和接收數據之前互相認證、協(xié)商加密算法和密鑰。在初次建立SSL連接時(shí)，服務(wù)器與客戶(hù)機交換一系列消息。
2> SSL修改密文協(xié)議：保障SSL傳輸過(guò)程中的安全性，客戶(hù)端和服務(wù)器雙方應該每隔一段時(shí)間改變加密規范
3> SSL報警協(xié)議：用來(lái)為對等體傳遞SSL的相關(guān)警告。如果在通信過(guò)程中某一方發(fā)現任何異常，就需要給對方發(fā)送一條警示消息通告。
1.第一階段：Handshake phase（握手階段）
協(xié)商加密算法
認證服務(wù)器
建立用于加密和MAC（Message Authentication Code）的會(huì )話(huà)密鑰
2.第二階段：Secure data transfer phase（安全數據傳輸階段）
在已經(jīng)建立的SSL數據通道里安全的傳輸數據
1）認證用戶(hù)和服務(wù)器，確保數據發(fā)送到正確的 客戶(hù)機和服務(wù)器
2）加密數據以防止數據中途被竊取
3）維護數據的完整性，確保數據在傳輸過(guò)程中不被改變。
當你在瀏覽器的地址欄上輸入https開(kāi)頭的網(wǎng)址后，瀏覽器和服務(wù)器之間會(huì )在接下來(lái)的幾百毫秒內進(jìn)行大量的通信：
認證服務(wù)器：瀏覽器內置一個(gè)受信任的CA機構列表，并保存了這些CA機構的證書(shū)。第一階段服務(wù)器會(huì )提供經(jīng)CA機構認證頒發(fā)的服務(wù)器證書(shū)，如果認證該服務(wù)器證書(shū)的CA機構，存在于瀏覽器的受信任CA機構列表中，并且服務(wù)器證書(shū)中的信息與當前正在訪(fǎng)問(wèn)的網(wǎng)站（域名等）一致，那么瀏覽器就認為服務(wù)端是可信的，并從服務(wù)器證書(shū)中取得服務(wù)器公鑰，用于后續流程。否則，瀏覽器將提示用戶(hù)，根據用戶(hù)的選擇，決定是否繼續。當然，我們可以管理這個(gè)受信任CA機構列表，添加我們想要信任的CA機構，或者移除我們不信任的CA機構。
在用SSL進(jìn)行通信之前，首先要使用SSL的Handshake協(xié)議在通信兩端握手，協(xié)商數據傳輸中要用到的相關(guān)安全參數（如加密算法、共享密鑰、產(chǎn)生密鑰所要的材料等），并對對端的身份進(jìn)行驗證。
客戶(hù)端首先發(fā)送ClientHello消息到服務(wù)端，服務(wù)端收到ClientHello消息后，再發(fā)送ServerHello消息回應客戶(hù)端。
客戶(hù)端瀏覽器向服務(wù)器端發(fā)送如下信息：
Version 版本號（客戶(hù)端支持的SSL /TLS協(xié)議的版本號。）
Random 客戶(hù)端產(chǎn)生的#隨機數#
Session id 會(huì )話(huà)ID
Cipher Suite（密鑰算法套件）：加密套件里面包含三部分：
1、加密算法；
2、完整性校驗算法（MD5，哈希算法）；
3：密鑰協(xié)商算法；主要看客戶(hù)端和服務(wù)端支持哪一個(gè)算法，客戶(hù)端會(huì )把自己支持的加密算法發(fā)送給服務(wù)端。
Compression Methods（壓縮算法）
預留
服務(wù)器端向客戶(hù)端發(fā)送如下信息：
服務(wù)器把自己支持的版本列出來(lái)，然后和客戶(hù)端進(jìn)行比較，拿出客戶(hù)端支持的最新版本
服務(wù)器端產(chǎn)生#隨機數#
服務(wù)端也列出加密套件，協(xié)商后使用統一的 加密套件
客戶(hù)端產(chǎn)生的會(huì )話(huà)ID寫(xiě)進(jìn)服務(wù)器里面
如果支持客戶(hù)端的壓縮算法，則使用
擴展包
在此階段之后通信雙方分別確定了：
1、SSL的版本；2、加密套件；3、壓縮算法；4、倆個(gè)隨機數
服務(wù)器向客戶(hù)端發(fā)送消息，本階段服務(wù)器是唯一發(fā)送方，客戶(hù)端是唯一接收方。
本階段共有四個(gè)消息，如下：
證書(shū)：服務(wù)器將數字證書(shū)和到根CA整個(gè)鏈發(fā)給客戶(hù)端，使客戶(hù)端能用服務(wù)器證書(shū)中的服務(wù)器公鑰認證服務(wù)器。
服務(wù)器密鑰交換（可選）：這里視密鑰交換算法而定。
證書(shū)請求：服務(wù)端可能會(huì )要求客戶(hù)自身進(jìn)行驗證。
服務(wù)器握手完成：第二階段的結束，第三階段開(kāi)始的信號
一般情況下，除了會(huì )話(huà)恢復時(shí)不需要發(fā)送該消息，在SSL握手的全過(guò)程中都需要該消息。消息中包含一個(gè)X.509證書(shū)，證書(shū)中包含公鑰，發(fā)給客戶(hù)端用來(lái)驗證簽名或者在密鑰交換時(shí)給消息加密。
這一步是服務(wù)端將自己的證書(shū)下發(fā)給客戶(hù)端，讓客戶(hù)端驗證自己的身份，客戶(hù)端驗證通過(guò)后取出證書(shū)中的公鑰，以便后面的使用。
根據之前的client hello消息中的cipther suite信息決定了，密鑰交換的方法（例如RSA和DH），因此在此消息中便會(huì )完成密鑰交換所需的一系列參數。
這一步是可選的，在安全性要求高的場(chǎng)合可以看到；服務(wù)端發(fā)送Certificate Request消息，請求客戶(hù)端發(fā)送他自己的證書(shū)來(lái)進(jìn)行驗證。該消息中包含服務(wù)器端支持的證書(shū)類(lèi)型（RSA、DSA、ECDSA），和服務(wù)器所信任的所有證書(shū)的發(fā)行機構的CA列表，客戶(hù)端會(huì )用這些信息來(lái)篩選證書(shū)。
表示服務(wù)器已將所有的信息發(fā)送完畢，等待客戶(hù)端發(fā)送消息
客戶(hù)端收到服務(wù)器發(fā)送的一系列消息并解析后，將本端相應的消息發(fā)送給服務(wù)器。
客戶(hù)機啟動(dòng)SSL握手第3階段，是本階段所有消息的唯一發(fā)送方，服務(wù)器是所有消息的唯一接收方。該階段分為3步：
證書(shū)（可選）：為了對服務(wù)器證明自身，客戶(hù)要發(fā)送一個(gè)證書(shū)信息，這是可選的，在IIS中可以配置強制客戶(hù)端證書(shū)認證。
客戶(hù)機密鑰交換（Pre-master-secret）：這里客戶(hù)端將預備主密鑰發(fā)送給服務(wù)端，注意這里會(huì )使用服務(wù)端的公鑰進(jìn)行加密。
證書(shū)驗證（可選）：對從第一條消息以來(lái)的所有握手消息進(jìn)行簽名。
如果在第二階段服務(wù)器要求客戶(hù)端發(fā)送證書(shū)，客戶(hù)端便會(huì )發(fā)送自己的證書(shū)，服務(wù)器端之前在發(fā)送的Certificate Request消息中包含了服務(wù)器所支持的證書(shū)類(lèi)型和CA列表，客戶(hù)端會(huì )在證書(shū)中找到滿(mǎn)足要求的一個(gè)發(fā)送給服務(wù)器。若客戶(hù)端沒(méi)有證書(shū)，則會(huì )發(fā)送一個(gè)no_certificate警告。
根據之前從服務(wù)端收到的隨機數，按照不同的密鑰交換算法，算出一個(gè)Pre-master，發(fā)送給服務(wù)器，服務(wù)器收到pre-master,算出一個(gè)main-master。而客戶(hù)端也能通過(guò)Pre-master自己算出一個(gè)main-master。如此一來(lái)，雙方就算出了對稱(chēng)密鑰。
如果是RSA算法，會(huì )生成一個(gè)48位的隨機數，然后用server的公鑰加密后放入報文中；如果是DH算法，發(fā)送的就是客戶(hù)端的DH參數，之后客戶(hù)端和服務(wù)端根據DH算法，計算出相同的Pre-master secret。
本消息在發(fā)送過(guò)程中，使用了服務(wù)器的公鑰加密，服務(wù)器在收到后需要用服務(wù)器的私鑰解密才能得到Pre-master Key。
只有在客戶(hù)端在發(fā)送了證書(shū)到服務(wù)端時(shí)，這個(gè)消息才需要發(fā)送，其中包含簽名，對從握手第一條消息以來(lái)的所有握手消息的HMAC值（用master_secret）進(jìn)行簽名。
完成握手協(xié)議，建立SSL連接。
該階段有四個(gè)消息交互，前兩個(gè)為客戶(hù)端發(fā)送，后兩個(gè)為服務(wù)器發(fā)送。
建立起一個(gè)安全的連接，客戶(hù)端發(fā)送一個(gè)Change Cipher spec消息，并且把協(xié)商得到的Cipher suite拷貝到當前連接的狀態(tài)之中。然后客戶(hù)端使用新的算法和密鑰參數發(fā)送一個(gè)Finished消息，這條消息可以檢測密鑰交換和認證過(guò)程是否已經(jīng)成功，其中包括一個(gè)校驗值，對客戶(hù)端整個(gè)握手消息進(jìn)行校驗。服務(wù)器同樣發(fā)送一個(gè)Change Cipher Spec消息和Finished消息。握手過(guò)程完成，客戶(hù)端和服務(wù)器可以交換應用層數據進(jìn)行通信。
編碼改變通知，表示隨后的信息將用雙方商定的加密算法和和密鑰發(fā)送（ChangeCipherSpec是一個(gè)獨立的協(xié)議，體現在數據包中就是一個(gè)字節的數據，用于告知服務(wù)端，客戶(hù)端已經(jīng)切換到之前協(xié)商好的加密套件（Cipher Suite）的狀態(tài)，準備使用之前協(xié)商好的加密套件加密數據并傳輸了）。
客戶(hù)端握手結束通知，表示客戶(hù)端的握手階段已經(jīng)結束。這一項同時(shí)也是前面所有發(fā)送的內容的hash值，用來(lái)供服務(wù)器校驗。（使用HMAC算法計算收到和發(fā)送的所有握手消息的摘要，加密后發(fā)送。此數據是為了在正式傳輸應用數據之前對剛剛握手建立起來(lái)的加解密通道進(jìn)行驗證。）
服務(wù)端握手結束通知。
使用私鑰解密加密的Pre-master數據，基于之前(Client Hello 和 Server Hello)交換的兩個(gè)明文隨機數 random_C 和 random_S，計算得到協(xié)商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master);
計算之前所有接收信息的hash值，然后解密客戶(hù)端發(fā)送的 encrypted_handshake_message，驗證數據和密鑰正確性;
發(fā)送一個(gè)Change Cipher Spec（告知客戶(hù)端已經(jīng)切換到協(xié)商過(guò)的加密套件狀態(tài)，準備使用加密套件和 Session Secret加密數據了）
服務(wù)端也會(huì )使用Session Secret加密一段Finish消息發(fā)送給客戶(hù)端，以驗證之前通過(guò)握手建立起來(lái)的加解密通道是否成功。
根據之前的握手信息，如果客戶(hù)端和服務(wù)端都能對Finish信息進(jìn)行正常加解密且消息正確的被驗證，則說(shuō)明握手通道已經(jīng)建立成功，接下來(lái)，雙方可以使用上面產(chǎn)生的Session Secret對數據進(jìn)行加密傳輸了。
會(huì )話(huà)恢復是指只要客戶(hù)端和服務(wù)器已經(jīng)通信過(guò)一次，它們就可以通過(guò)會(huì )話(huà)恢復的方式來(lái)跳過(guò)整個(gè)握手階段而直接進(jìn)行數據傳輸。SSL采用會(huì )話(huà)恢復的方式來(lái)減少SSL握手過(guò)程中造成的巨大開(kāi)銷(xiāo)。此功能從之前的13步減少到6步，大大減少了開(kāi)銷(xiāo)。
兩種會(huì )話(huà)機制
會(huì )話(huà)標識 session ID: 由服務(wù)器端支持，協(xié)議中的標準字段，因此基本所有服務(wù)器都支持，服務(wù)器端保存會(huì )話(huà)ID以及協(xié)商的通信信息，Nginx 中1M 內存約可以保存4000個(gè) session ID 機器相關(guān)信息，占用服務(wù)器資源較多;
會(huì )話(huà)記錄 session ticket :需要服務(wù)器和客戶(hù)端都支持，屬于一個(gè)擴展字段，支持范圍約60%(無(wú)可靠統計與來(lái)源)，將協(xié)商的通信信息加密之后發(fā)送給客戶(hù)端保存，密鑰只有服務(wù)器知道，占用服務(wù)器資源很少。
二者對比，主要是保存協(xié)商信息的位置與方式不同，類(lèi)似與 http 中的 session 與 cookie。二者都存在的情況下，(nginx 實(shí)現)優(yōu)先使用 session_ticket。
恢復過(guò)程
如果服務(wù)器和客戶(hù)端之間曾經(jīng)建立過(guò)連接，服務(wù)器會(huì )在握手成功后返回一個(gè)session ID，并保存對應的參數在服務(wù)器中。如果客戶(hù)端和服務(wù)器需要再次連接，則需要在Client hello消息中攜帶記錄的信息，返回給服務(wù)器。服務(wù)器根據收的到的Session ID檢索緩存記錄，如果有緩存，則返回一個(gè)Change Cipher Spec消息和Finished消息，如果沒(méi)有緩存則正常進(jìn)行握手。如果客戶(hù)端能夠驗證通過(guò)服務(wù)器加密數據，則同樣回復一個(gè)Change Cipher Spec消息和Finished消息。服務(wù)器驗證通過(guò)則握手建立成功，開(kāi)始進(jìn)行正常的加密數據通信。
SSL記錄協(xié)議主要用于實(shí)現對數據的分塊、加密解密、壓縮解壓縮、完整性檢測和封裝各種高層協(xié)議。
主要包括：
內容類(lèi)型
協(xié)議版本號
記錄數據的長(cháng)度
數據有效載荷
散列算法計算消息認證代碼
將上層分下來(lái)的數據包分成合適的數據塊，但是每個(gè)數據塊不得超過(guò)214字節。
對每個(gè)數據塊進(jìn)行壓縮，但是不能丟失數據信息。
計算壓縮后的數據消息認證碼MAC，并添加在壓縮包后。添加后總長(cháng)度不得超過(guò)2262字節。
對稱(chēng)密碼加密。
給SSL添加一個(gè)首部。其中包括:內容類(lèi)型、主要版本、次要版本、壓縮長(cháng)度等信息。通過(guò)以上過(guò)程把原始的數據加密為SSL協(xié)議的記錄集。
參考：https://blog.csdn.net/weixin_43997530/article/details/108048388
聯(lián)系客服
