介紹

SSL:Secure Socket Layer 安全套接字層。

TLS:Transport layer Security 傳輸層安全性，是一種加密協(xié)議。

發(fā)展歷程

到2020年，SSL以及TLS1.0，TLS1.1已被棄用

TLS用在哪里？

為什么用TLS？

Authentication:通信雙方可以確認雙方的身份，不被黑客攔截信息偽造身份。

Confidentiality：通信的內(nèi)容經(jīng)過加密，更加安全,不被授權(quán)的用戶無法識別內(nèi)容。

Integroty：通訊內(nèi)容可以查出是否被破壞。

TLS是怎么工作的？

兩階段：

1. 握手階段，雙方通過非對稱加密通信，建立連接，傳輸用于加密數(shù)據(jù)的對稱秘鑰

2. 通信階段，雙方通過對稱秘鑰加密數(shù)據(jù)，互相通信

為什么TLS同時采用了非對稱加密和對稱加密呢？

1. 只用對稱加密的話，我們不能保證雙方在商量秘鑰是什么的情況下秘鑰在網(wǎng)絡(luò)傳輸中不被泄露，也不能確認信息是否被修改了。

2. 如果只用非對稱加密的話，它比對稱加密的效率要低上成千上萬倍。

對稱密碼學

一般對稱加密方式，發(fā)送方和接收方共享一個秘鑰，發(fā)送方利用秘鑰加密，接收方利用秘鑰解密。

上述的加密，黑客可以對信息攔截并進行位翻轉(zhuǎn)來進行攻擊。請看下面的例子。

由于信息可能會被篡改，所以現(xiàn)在還需要進行驗證信息的真?zhèn)巍?/p>

所以要為傳輸?shù)男畔⒏缴向炞C信息。

帶有驗證信息的對稱加密過程：

1. 根據(jù)秘鑰 secret key和初始向量 IV 通過對稱加密算法，對明文進行加密。

2. 將秘鑰，初始向量，密文通過MAC算法，生成HASH串，作為驗證code。使用MAC算法時我們還可以添加一些附加信息，這些信息是明文的，且應當是雙方知道的。

3. 將驗證code附加到密文上，一起傳輸。

帶有驗證信息的解密過程：

1. 將驗證信息取出。

2. 將秘鑰 ，IV，附加信息，密文通過MAC算法得到新的hash串。

3. 比較兩個hash串是否一致，一致就可以通過秘鑰和IV進行解密得到明文

現(xiàn)在還存在一個問題？雙方是怎么共享秘鑰的？

為了保證傳輸過程中秘鑰的安全性，我們通過非對稱加密來共享秘鑰。非對稱加密的具體流程在下面有專門的講述。

首先雙方生成各自的私鑰和公鑰，生成的算法有很多，RSA算法，ECC算法（與橢圓曲線有關(guān)）

下面介紹的是Diffile-Hellman Ephemeral（DHE）

g是一個公知的冪的底,p為公知的一個模。g,p是雙方都認可的一個值

雙方各自選擇一個值作為自己的私鑰，比如說發(fā)送方為a，接收方為b。

然后雙方計算出各自的公鑰A,B，并且傳送給對方。

雙方收到后通過計算可以得到S，這個值雙方計算出來是一樣的。如何計算看下圖。

雙方就可以通過S這個共享秘鑰來進行數(shù)據(jù)加密。

現(xiàn)在還存在一個問題，S的長度是不固定的，我們還需要用HKDF進行一次轉(zhuǎn)換，把它轉(zhuǎn)換為確切長度的key。

HKDF(H mark base key derivation functon)

p,g,A,B對公眾來說都是已知的，黑客是否可以通過p,g,A,B算出a,b的值來呢？

我們可以看到 p有2048bit,a,b各有256bit。

算法很簡單，但是很難算出來

但是如果我們多次對話都用同樣的a,b的話，早晚會被算出來

所以我們應使用臨時秘鑰，每一次會話都重新商議秘鑰

成熟的非對稱加密算法有RSA，EEC

RSA：類似于剛才說的那種生成私鑰和公鑰的方法。

EEC: 在生成公鑰和私鑰時，用到的橢圓曲線。具體如何不展開。

下面是EEC,RSA秘鑰位數(shù)與安全級別的對比

非對稱加密算法

通過DHE，ECDHE實現(xiàn)隱秘的共享秘鑰的交換

加密是怎么運轉(zhuǎn)的

雙方之間公鑰的傳輸，在這個過程中，public key可以被黑客攔截，偽造public key重新發(fā)送給接收方。此時當接收方用偽造的public key進行加密時，黑客便可以通過他的私鑰進行解密。造成這樣現(xiàn)象的原因是因為public key 沒有任何的驗證信息，接收方無法確認public key到底來自誰。

所以現(xiàn)在我們需要加入適當?shù)尿炞C信息，通過可靠的第三方認證機構(gòu)，生成數(shù)字證書

CA證書的簽發(fā)過程

1. 創(chuàng)建一個certificate siging request(CSR),這個CSR中包含public key和發(fā)送方的一些身份信息。

2. 發(fā)送方用private key 對CSR進行數(shù)字簽名。

3. CA接收到后，根據(jù)csr中的public key 對簽名進行解簽，并且驗簽。

4. CA認證完成后，對內(nèi)容用CA私鑰進行簽名，最后將簽名以及明文的信息返回給申請者。

數(shù)字證書的驗證

發(fā)送方發(fā)送證書到接收方，接受方通過CA的public key進行驗簽便可知道是否安全。

在此過程中，如果黑客修改了證書內(nèi)容，那么接受方在驗簽的過程中就不會通過。

黑客因為不知道CA的私鑰所以也無法偽造證書。

數(shù)字簽名的過程

對信息進行HASH得到摘要，用私鑰對摘要進行加密，最后將簽名附在原文上。

驗簽過程

收到信息后，將原文和簽名分開。

用公鑰對簽名解簽得到摘要1。

原文按照相同的hash算法得到摘要2。

比較摘要1和摘要2。

Chain of trust

最上層為的CA的證書是自簽的。

根CA對下面的CA進行簽名。一層一層。

TLS 1.3 HandShake

1. client 發(fā)送hello message ,主題內(nèi)容包括支持的tls版本，支持的密碼套件（基本的形式是「密鑰交換算法 + 簽名算法 + 對稱加密算法 + 摘要算法」），支持的非對稱加密共享秘鑰的交換策略，公鑰的類型，以及支持的簽名算法，這個用于對handshake過程中的簽名，其中包括一個隨機數(shù)1。

這是TLS 的第一次握手。

2. server發(fā)送hello message，內(nèi)容包括

這是TLS的第二次握手，server會選擇tls版本，密碼套件，共享秘鑰的交換組，公鑰的類型，對client證書的請求（這個是可選的，當server需要驗證client的身份時），然后server會生成一個隨機數(shù)2，并將上述的信息，連同server的證書，握手上下文（從開始握手到對client證書的請求之間的上下文）與服務(wù)器證書的簽名（簽名過程用server的private key和client 提供的簽名算法進行簽名），握手上下文+server證書+verify的mac（先hash再通過選擇的AEAD套件中的mac算法進行mac運算）,發(fā)送回去。

Server Certificate + Certificate verify +Server Finish 保證了在handshake過程中的安全。

3. client收到server的確認信息后，通過根證書來驗證簽名，并確定是否信息被修改。

4. 這是TLS的第三次握手，client驗證完后會生成隨機數(shù)3，并用server的公鑰進行了加密，服務(wù)器收到后會用私鑰解密得到隨機數(shù)3，此時，雙方都有了三個隨機數(shù)，這三個隨機數(shù)生成會話密鑰，將自身的證書，隨機數(shù)3，verify,mac，change cipher Spec(告訴服務(wù)端后續(xù)將進行加密通訊)發(fā)送到server。

5. server同樣發(fā)送change cipher Spec(告訴客戶端后續(xù)將進行加密通訊)和mac到client

后續(xù)就是利用會話密鑰進行會話的過程了。

Resumption & Pre-Shared-Key

但是服務(wù)器在與客戶端會話時，并不會總是采用上述的握手方式，上述方式太過繁瑣。有時他們會通過pre shared key來進行簡單的握手。

原理是在上一次握手之后，通信雙方已經(jīng)彼此認識，因此不需要再進行身份認證。

1. 服務(wù)器可以向client發(fā)送一個或多個session ticket（會話憑證），這個憑證可以在下一次握手時使用，PSK identity是對PMS的標識。

2. 下一次握手時，client會發(fā)送hello message 內(nèi)容有session ticket list，以及相關(guān)的PSK模式，等信息。

3. server 發(fā)送hello message，內(nèi)容包括選定的PSK，以及mac

4. client確認發(fā)送回mac。

可以看出這次握手沒有證書的驗證過程，只是利用了上次握手確認的詳細信息，此次握手僅通過PSK來恢復上次現(xiàn)場。

在這基礎(chǔ)上，我們可以在handshake的hello message 的發(fā)送中附加上要傳輸?shù)臄?shù)據(jù)。

TLS1.3與1.2的對比。

如何用Openssl來簽發(fā)證書和創(chuàng)建私鑰？

1. 在本地模擬CA認證機構(gòu)，先為自己創(chuàng)建一個私鑰，以及自簽證書（簽名時用的自己的私鑰）

openssl req -x509 -newkey rsa:4096 -days 365 -nodes -keyout ca-key.pem -out ca-cert.pem -subj "/C=CH/ST=GANSU/L=LANZHOU/O=LZU/OU=HIGHSCHOOL/CN=*.tech.xiaobai/emailAddress=techschool@gmail.com"
req 代表生成證書請求 -x509 可以理解為一種證書的形式，-newKey 用來創(chuàng)建私鑰 rsa:4096表示用
rsa算法生成4096位的私鑰。-days 365為證書的有效期 -nodes是我們在開發(fā)時不對私鑰文件加密，
-keyout 私鑰的輸出文件，-out 證書的輸出文件，
-subj 為創(chuàng)建證書時的附件信息，包括”國家，地區(qū)，組織，機構(gòu)，郵箱等等“。

openssl x509 -in ca-cert.pem -noout -text 用來將證書轉(zhuǎn)為人類可識別的格式
x509格式 -in 指定證書文件 -noout 指不將格式化的內(nèi)容輸出為文件 -text 文本形式顯示

2. 為server端創(chuàng)建私鑰并簽名一個certificate signing request (CSR)。

openssl req -newkey rsa:4096 -nodes  -keyout server-key.pem  -out server-req.pem -subj "/C=CH/ST=GANSU/L=LANZHOU/O=PC BOOK/OU=computer/CN=*.pcbook.com/emailAddress=pcbook@gmail.com"
因為我們這里并不是生成證書，所以沒有-x509參數(shù)，而是生成了私鑰和帶有附加信息的CSR。

3. CA驗證CSR并且簽名。文章來源地址http://www.zghlxwxcb.cn/news/detail-759277.html

openssl x509 -req -in server-req.pem -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem
x509 證書形式， -req 來生成證書， -in 要簽名的證書， -CA CA的證書，-CAkey ca用來簽名的秘鑰， -CAcreateserial 
每次簽名生成一個唯一的序列號。
-out 生成的證書