加密算法

對稱加密

加密和解密都是使用的同一個密鑰。

非對稱加密

非對稱加密使用一對“私鑰-公鑰”，用私鑰加密的內容只有對應公鑰才能解開，反之亦然。非對稱加密有以下特性：

對於一個公鑰，有且只有一個對應的私鑰。
公鑰是公開的，並且不能通過公鑰反推出私鑰。
通過私鑰加密的密文只能通過公鑰能解密，通過公鑰加密的密文也只能通過私鑰能解密。

常見的非對稱加密有 RSA、ESA、ECC 等。缺點：

一次完全 TLS 握手，密鑰交換時的非對稱解密計算量佔整個握手過程的 90% 以上。而對稱加密的計算量只相當於非對稱加密的 0.1%，如果應用層數據也使用非對稱加解密，性能開銷太大，無法承受。
非對稱加密算法對加密內容的長度有限制，不能超過公鑰長度。比如現在常用的公鑰長度是 2048 位，意味着待加密內容不能超過 256 個字節。

摘要算法

所謂信息摘要，其實就是某種HASH算法。將信息明文轉化爲固定長度的字符。摘要算法有以下特性：

只要源文本不同，計算得到的結果，必然不同（或者說機會很少）。
無法從結果反推出源數據。

基於以上特性，我們一般使用摘要算法來校驗原始內容是否被篡改。常見的摘要算法有 MD5、SHA 等。

證書

SSL證書根據驗證級別，分爲三種類型：

域名型SSL證書，簡稱DVSSL；
企業型SSL證書，簡稱OVSSL；
增強型SSL證書，簡稱EVSSL。

除了驗證級別維度的不同，統一級別的證書，它又根據保護域名的數量需求，SSL 證書又分爲：

單域名版：只保護一個域名，例如 www.abc.com 或者 login.abc.com 之類的單個域名
多域名版：一張證書可以保護多個域名，例如同時保護 www.abc.com , www.bcd.com, pay.efg.com 等
通配符版：一張證書保護同一個主域名下同一級的所有子域名，不限個數，形如 *.abc.com 。注意，通配符版只有 DVSSL 和 OVSSL 具有， EVSSL 不具有通配符版本。

細說 CA 和證書講的比較詳細。

什麼是數字簽名

數字簽名就是用摘要算法（MD5、SHA等）提取出源文件的摘要並用私鑰進行加密後的內容。用於驗證傳輸的內容是不是真實服務器發送的數據，發送的數據有沒有被篡改過。

什麼是證書

數字證書中包含了由某個受信任組織擔保的用戶或公司的相關信息，是爲了解決“客戶端”如何驗證”服務端“提供的公鑰是否是真的的問題。
數字證書裏一般會包含公鑰、公鑰擁有者名稱、CA 的數字簽名、有效期、授權中心名稱、證書序列號等信息。

什麼是CA？

CA是Certificate Authority的縮寫，也叫“證書授權中心”。（專業的解釋看“這裏”），負責管理和簽發證書的第三方機構

爲什麼要證書

數字證書有兩個作用：

身份授權。確保瀏覽器訪問的網站是經過 CA 驗證的可信任的網站。
分發公鑰。每個數字證書都包含了註冊者生成的公鑰。在 SSL 握手時會通過 certificate 消息傳輸給客戶端。

如何確認這個證書就是 CA 簽發

答案就是數字簽名（digital signature）。數字簽名可以認爲是一個證書的防僞標籤，目前使用最廣泛的 SHA-RSA 數字簽名的製作和驗證過程如下：

數字簽名的簽發。首先是使用哈希函數對證書數據哈希，生成消息摘要，然後使用 CA 自己的私鑰對證書內容和消息摘要進行加密。
數字簽名的校驗。使用 CA 的公鑰解密簽名，然後使用相同的簽名函數對證書內容進行簽名並和服務端的數字簽名裏的簽名內容進行比較，如果相同就認爲校驗成功。

幾點說明：

數字簽名簽發和校驗使用的密鑰對是 CA 自己的公私密鑰，跟證書申請者提交的公鑰沒有關係。
數字簽名的簽發過程跟公鑰加密的過程剛好相反，即是用私鑰加密，公鑰解密。
現在大的 CA 都會有證書鏈，證書鏈的好處一是安全，保持根 CA 的私鑰離線使用。第二個好處是方便部署和撤銷，即如何證書出現問題，只需要撤銷相應級別的證書，根證書依然安全。
根 CA 證書都是自簽名， 即用自己的公鑰和私鑰完成了簽名的製作和驗證。而證書鏈上的證書籤名都是使用上一級證書的密鑰對完成簽名和驗證的。
怎樣獲取根 CA 和多級 CA 的密鑰對？它們是否可信？當然可信，因爲這些廠商跟瀏覽器和操作系統都有合作，它們的公鑰都默認裝到了瀏覽器或者操作系統環境裏。比如 firefox 就自己維護了一個可信任的 CA 列表，而 chrome 和 IE 使用的是操作系統的 CA 列表。

客戶端怎麼驗證證書

證書信任鏈機制

實際上，在HTTPS通信中，Server下發給Client的不僅僅是對端網站的證書，而是一個證書鏈。這個證書鏈是從網站證書開始，逐級往上，到根證書。每個證書都被下個證書的私鑰簽署，每個證書的 Issuer 就是下個證書的 Subject，root CA內置在瀏覽器中，是被瀏覽器所信任的。

參考：
大型網站的 HTTPS 實踐（一）-- HTTPS 協議和原理
 互聯網安全之數字簽名、數字證書與PKI系統

TLS（SSL）協議

TLS 協議主要有五部分：應用數據層協議，握手協議，報警協議，加密消息確認協議，心跳協議。TLS 協議本身又是由 record 協議傳輸的，record 協議的格式如上圖最右所示。

ssl記錄協議（SSL Record Protocol）

記錄協議在客戶機和服務器握手成功後使用，即客戶機和服務器鑑別對方和確定安全信息交換使用的算法後，進入SSL記錄協議，記錄協議向SSL連接提供兩個服務：
（1）保密性：使用握手協議定義的祕密密鑰實現
（2）完整性：握手協議定義了MAC，用於保證消息完整性
爲高層協議提供數據封裝、壓縮、加密等基本功能的支持。

SSL握手協議（SSL Handshake Protocol）

它建立在SSL記錄協議之上，用於在實際的數據傳輸開始前，通訊雙方進行身份認證、協商加密算法、交換加密密鑰等。

具體過程

上圖來自Https詳解

客戶端發出請求（ClientHello）

這一步，客戶端主要向服務器提供以下信息：

（1） 支持的協議版本，比如TLS 1.0版。
（2） 一個客戶端生成的隨機數（Random1），稍後用於生成"對話密鑰"（session key）。
（3） 支持的加密套件，比如RSA公鑰加密。
（4） 支持的壓縮方法。
（5） session ID （支持session的一般會有這個）

鏈接重用

TLS 握手階段需要9次請求，非常耗時。鏈接重用目前有兩種方式
session ID 會話複用

對於已經建立的SSL會話，使用session id爲key（session id來自第一次請求的server hello中的session id字段），主密鑰爲value組成一對鍵值，保存在本地，服務器和客戶端都保存一份。

當第二次握手時，客戶端若想使用會話複用，則發起的client hello中session id會置上對應的值，服務器收到這個client hello，解析session id，查找本地是否有該session id，如果有，判斷當前的加密套件和上個會話的加密套件是否一致，一致則允許使用會話複用，於是自己的server hello 中session id也置上和client hello中一樣的值。然後計算對稱祕鑰，解析後續的操作。

如果服務器未查到客戶端的session id指定的會話（可能是會話已經老化），則會重新握手，session id要麼重新計算（和client hello中session id不一樣），要麼置成0，這兩個方式都會告訴客戶端這次會話不進行會話複用。
– 來自 TLS/SSL 協議詳解 (22)會話複用

Session ticket會話複用

Session id會話複用有2個缺點：

服務器會大量堆積會話，對服務器內存佔用非常高。
如果服務器是集羣模式搭建，那麼客戶端和A各自保存的會話，在合B嘗試會話複用時會失敗。即服務器集羣需要做Session id的同步。

Session ticket的工作流程如下：

客戶端發起client hello，拓展中帶上空的session ticket TLS，表明自己支持session ticket。
服務器在握手過程中，如果支持session ticket，則發送New session ticket類型的握手報文，其中包含了能夠恢復包括主密鑰在內的會話信息，當然，最簡單的就是隻發送master key。爲了讓中間人不可見，這個session ticket部分會進行編碼、加密等操作。
客戶端收到這個session ticket，就把當前的master key和這個ticket組成一對鍵值保存起來。服務器無需保存任何會話信息，客戶端也無需知道session ticket具體表示什麼。
當客戶端嘗試會話複用時，會在client hello的拓展中加上session ticket，然後服務器收到session ticket，回去進行解密、解碼能相關操作，來恢復會話信息。如果能夠恢復會話信息，那麼久提取會話信息的主密鑰進行後續的操作。

兩者的主要區別，就是加密的握手記錄誰負責保存的問題。Session ID 是服務端保存握手記錄，Session Ticket 是客戶端保存握手記錄。

服務器迴應（SeverHello）

SeverHello包含以下內容：

（1） 確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。
（2） 一個服務器生成的隨機數(Random2)，稍後用於生成"對話密鑰"（session key）。
（3） 確認使用的加密方法，比如RSA公鑰加密。
（4） session ID

Certificate
服務端將自己的證書下發給客戶端，讓客戶端驗證自己的身份，客戶端驗證通過後取出證書中的公鑰。

Server Key Exchange
僅用於（服務器）證書消息沒有包含足夠的信息來建立預置密鑰（pre-master key）的情況。如短暫的DH算法，這裏發送服務器使用的DH參數。RSA算法不需要這一步。

Certificate Request
服務端要求客戶端上報證書，這一步是可選的，需要雙向認證時要用到。

Server Hello Done
Server Hello Done 通知客戶端 Server Hello 過程結束。

客戶端迴應

客戶端在接受到服務端發來的SSL證書時，會對證書的真僞進行校驗，以瀏覽器爲例說明如下：

（1）首先瀏覽器讀取證書中的證書所有者、有效期等信息進行一一校驗
（2）瀏覽器開始查找操作系統中已內置的受信任的證書發佈機構CA，與服務器發來的證書中的頒發者CA比對，用於校驗證書是否爲合法機構頒發
（3）如果找不到，瀏覽器就會報錯，說明服務器發來的證書是不可信任的。
（4）如果找到，那麼瀏覽器就會從操作系統中取出頒發者CA 的公鑰，然後對服務器發來的證書裏面的簽名進行解密
（5）瀏覽器使用相同的hash算法計算出服務器發來的證書的hash值，將這個計算的hash值與證書中籤名做對比
（6）對比結果一致，則證明服務器發來的證書合法，沒有被冒充
（7）此時瀏覽器就可以讀取證書中的公鑰（服務端的公鑰），用於後續加密了。
（8）客戶端再生成一個隨機數 Random3，又稱"pre-master key"。有了它以後，客戶端和服務器就同時有了三個隨機數，接着雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。

至於爲什麼一定要用三個隨機數，來生成"會話密鑰"，dog250解釋得很好，總結來說就是爲了增加隨機性，不容易被暴力破解。SSL協議不信任每個主機都能生成完全隨機的隨機數。同時需要注意前兩個隨機數都是明文傳輸的，竊聽者是可以輕易獲取到的，只有最後一個 PreMaster Secret 是加密傳輸的，只有擁有服務器私鑰才能解密，一旦 PreMaster Secret 泄露，那麼本次通信就就完全可被破解了。

Client Key Exchange
上面客戶端根據服務器傳來的公鑰生成了 pre-master Key，Client Key Exchange 就是將這個 key 傳給服務端，服務端再用自己的私鑰解出這個 PreMaster Key 得到客戶端生成的 Random3。至此，客戶端和服務端都擁有 Random1 + Random2 + Random3，兩邊再根據同樣的算法就可以生成一份祕鑰，握手結束後的應用層數據都是使用這個祕鑰進行對稱加密。

Change Cipher Spec
這一步是客戶端通知服務端後面再發送的消息都會使用前面協商出來的祕鑰加密了，是一條事件消息。

Change Cipher Spec 有必要麼？
Change Cipher Spec 用來通知對端，開始啓用協商好的密鑰做對稱加密，內容只有1個字節。這個協議是冗餘的，在TLS 1.3裏面直接被刪除了。

Encrypted Handshake Message
這一步對應的是 Client Finish 消息，客戶端將前面的握手消息生成摘要再用協商好的祕鑰加密，這是客戶端發出的第一條加密消息。服務端接收後會用祕鑰解密，能解出來說明前面協商出來的祕鑰是一致的。

服務器的最後迴應

服務器收到客戶端的第三個隨機數pre-master key之後，計算生成本次會話所用的"會話密鑰"。

Change Cipher Spec
這一步是服務端通知客戶端後面再發送的消息都會使用加密，也是一條事件消息。

Encrypted Handshake Message
這一步對應的是 Server Finish 消息，服務端也會將握手過程的消息生成摘要再用祕鑰加密，這是服務端發出的第一條加密消息。客戶端接收後會用祕鑰解密，能解出來說明協商的祕鑰是一致的。

總結 SSL/TLS協議的基本過程是這樣的：

（1）客戶端向服務器端索要並驗證公鑰。
（2）雙方協商生成"對話密鑰"（session key）。（只有雙方知道，一共需要三個隨機數）
（3）雙方採用"對話密鑰"進行加密通信。（不直接用公鑰加密，因爲公鑰加密計算量太大，服務器的公鑰和私鑰只用於加密和解密對話密鑰（確切的來說是第三個隨機數），無其他作用。）關於隨機數的介紹。

在SSL中會使用密鑰交換算法交換密鑰；使用密鑰對數據進行加密；使用散列算法對數據的完整性進行驗證，使用數字證書證明自己的身份。

https

不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文傳播，帶來了三大風險。

（1）竊聽風險（eavesdropping）：通信使用明文，可能會被第三方可以獲知通信內容。
（2）篡改風險（tampering）：無法證明報文完整性，第三方可以修改通信內容。
（3）冒充風險（pretending）：不驗證通信方的身份，第三方可以冒充他人身份參與通信。

SSL/TLS協議是爲了解決這三大風險而設計的，希望達到：

（1）所有信息都是加密傳播，第三方無法竊聽。
（2）具有校驗機制，一旦被篡改，通信雙方會立刻發現。
（3）配備身份證書，防止身份被冒充。

https部署

golang 部署參考Go和HTTPS

用curl模擬請求注意幾點：

如果要用生成server.csr設置CN域名訪問，則需要在證書籤名請求的時候在hosts中添加相應的ip映射
用curl模擬請求的時候，單向認證用-k選項來跳過客戶端對服務端證書的檢測，即用
curl -k https://localhost:8081,否則要加上--cacert RootCA.crt。雙向認證時，除了跳過證書檢查，還要加上客戶端證書、私鑰，證書編碼需是pem格式。即curl -k --cert Client.pem --key Client.key https://localhost:8081

抓包工具原理

爲什麼客戶端會通過抓包工具的驗證？
抓包工具要成功抓取https的內容，首先需要在本地（客戶端）安裝抓包工具的根證書，這樣，本地就認爲抓包工具是合法的了（抓包工具的證書就能通過本地的驗證）。

參考

SSL/TLS 握手過程詳解
 基於OpenSSL自建CA和頒發SSL證書
 HTTPS 溫故知新（三） —— 直觀感受 TLS 握手流程(上)比較詳細的介紹
HTTPS 溫故知新（四） —— 直觀感受 TLS 握手流程(下)

HTTPS詳細整理（乾貨）