refs:
SSL雙向認證和SSL單向認證的區別
https://www.jianshu.com/p/fb5fe0165ef2
圖解 https 單向認證和雙向認證！
https://cloud.tencent.com/developer/news/233610
SSL/TLS 雙向認證(一) -- SSL/TLS工作原理
https://blog.csdn.net/wuliganggang/article/details/78428866
雙向認證 SSL 協議要求服務器和用戶雙方都有證書。單向認證 SSL 協議不需要客戶擁有CA證書
SSL單向認證具體過程
image.png
-
①客戶端的瀏覽器向服務器傳送客戶端SSL協議的版本號，加密算法的種類，產生的隨機數，以及其他服務器和客戶端之間通訊所需要的各種信息。
-
②服務器向客戶端傳送SSL協議的版本號，加密算法的種類，隨機數以及其他相關信息，同時服務器還將向客戶端傳送自己的證書。
-
③客戶利用服務器傳過來的信息驗證服務器的合法性，服務器的合法性包括：證書是否過期，發行服務器證書的CA是否可靠，發行者證書的公鑰能否正確解開服務器證書的"發行者的數字簽名"，服務器證書上的域名是否和服務器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開;如果合法性驗證通過，將繼續進行第四步。
-
④用戶端隨機產生一個用於後面通訊的"對稱密碼"，然後用服務器的公鑰(服務器的公鑰從步驟②中的服務器的證書中獲得)對其加密，然後將加密後的"預主密碼"傳給服務器。
-
⑤如果服務器要求客戶的身份認證(在握手過程中爲可選)，用戶可以建立一個隨機數然後對其進行數據簽名，將這個含有簽名的隨機數和客戶自己的證書以及加密過的"預主密碼"一起傳給服務器。
-
⑥如果服務器要求客戶的身份認證，服務器必須檢驗客戶證書和簽名隨機數的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，爲客戶提供證書的CA是否可靠，發行CA 的公鑰能否正確解開客戶證書的發行CA的數字簽名，檢查客戶的證書是否在證書廢止列表(CRL)中。檢驗如果沒有通過，通訊立刻中斷;如果驗證通過，服務器將用自己的私鑰解開加密的"預主密碼 "，然後執行一系列步驟來產生主通訊密碼(客戶端也將通過同樣的方法產生相同的主通訊密碼)。
-
⑦服務器和客戶端用相同的主密碼即"通話密碼"，一個對稱密鑰用於SSL協議的安全數據通訊的加解密通訊。同時在SSL通訊過程中還要完成數據通訊的完整性，防止數據通訊中的任何變化。
-
⑧客戶端向服務器端發出信息，指明後面的數據通訊將使用的步驟⑦中的主密碼爲對稱密鑰，同時通知服務器客戶端的握手過程結束。
-
⑨服務器向客戶端發出信息，指明後面的數據通訊將使用的步驟⑦中的主密碼爲對稱密鑰，同時通知客戶端服務器端的握手過程結束。
-
⑩-SSL的握手部分結束，SSL安全通道的數據通訊開始，客戶和服務器開始使用相同的對稱密鑰進行數據通訊，同時進行通訊完整性的檢驗。
SSL單向認證只要求站點部署了ssl證書就行，任何用戶都可以去訪問(IP被限制除外等)，只是服務端提供了身份認證。
SSL雙向認證具體過程
image.png
-
① 瀏覽器發送一個連接請求給安全服務器。
-
② 服務器將自己的證書，以及同證書相關的信息發送給客戶瀏覽器。
-
③ 客戶瀏覽器檢查服務器送過來的證書是否是由自己信賴的CA中心（如沃通CA）所簽發的。如果是，就繼續執行協議;如果不是，客戶瀏覽器就給客戶一個警告消息：警告客戶這個證書不是可以信賴的，詢問客戶是否需要繼續。
-
④ 接着客戶瀏覽器比較證書裏的消息，例如域名和公鑰，與服務器剛剛發送的相關消息是否一致，如果是一致的，客戶瀏覽器認可這個服務器的合法身份。
-
⑤ 服務器要求客戶發送客戶自己的證書。收到後，服務器驗證客戶的證書，如果沒有通過驗證，拒絕連接;如果通過驗證，服務器獲得用戶的公鑰。
-
⑥ 客戶瀏覽器告訴服務器自己所能夠支持的通訊對稱密碼方案。
-
⑦ 服務器從客戶發送過來的密碼方案中，選擇一種加密程度最高的密碼方案，用客戶的公鑰加過密後通知瀏覽器。
-
⑧ 瀏覽器針對這個密碼方案，選擇一個通話密鑰，接着用服務器的公鑰加過密後發送給服務器。
-
⑨ 服務器接收到瀏覽器送過來的消息，用自己的私鑰解密，獲得通話密鑰。
-
⑩ 服務器、瀏覽器接下來的通訊都是用對稱密碼方案，對稱密鑰是加過密的。
雙向認證則是需要服務端與客戶端提供身份認證，只能是服務端允許的客戶能去訪問，安全性相對於要高一些。
SSL/TLS 工作流
圖一 SSL/TLS 工作流
CA: 證書授權中心( certificate authority)。 它呢，類似於國家出入境管理處一樣，給別人頒發護照；也類似於國家工商管理局一樣，給公司企業頒發營業執照。
它有兩大主要性質：
1) CA本身是受信任的 // 國際認可的
2) 給他受信任的申請對象頒發證書 // 和辦理護照一樣，要確定你的合法身份，你不能是犯罪分子或造反派。當然，你需要被收保護費，同時，CA可以隨時吊銷你的證書。
證書長啥樣？其實你的電腦中有一堆CA證書。你可以看一看嘛：
360瀏覽器: 選項/設置-> 高級設置 -> 隱私於安全 -> 管理 HTTPS/SSL 證書 -> 證書頒發機構
火狐瀏覽器: 首選項 -> 高級 -> 證書 -> 查看證書 -> 證書機構
chrome瀏覽器: 設置 -> 高級 -> 管理證書 -> 授權中心
ubuntu: /etc/ssl/certs
這些都是 CA 的證書！
CA 的證書 ca.crt 和 SSL Server的證書 server.crt 是什麼關係呢？
1) SSL Server 自己生成一個 私鑰/公鑰對。server.key/server.pub // 私鑰加密，公鑰解密！
2) server.pub 生成一個請求文件 server.req. 請求文件中包含有 server 的一些信息，如域名/申請者/公鑰等。
3) server 將請求文件 server.req 遞交給 CA，CA驗明正身後，將用 ca.key和請求文件加密生成 server.crt
4) 由於 ca.key 和 ca.crt 是一對, 於是 ca.crt 可以解密 server.crt.
在實際應用中：如果 SSL Client 想要校驗 SSL server.那麼 SSL server 必須要將他的證書 server.crt 傳給 client.然後 client 用 ca.crt 去校驗 server.crt 的合法性。如果是一個釣魚網站，那麼CA是不會給他頒發合法server.crt證書的，這樣client 用ca.crt去校驗，就會失敗。比如瀏覽器作爲一個 client,你想訪問合法的淘寶網站https://www.taobao.com, 結果不慎訪問到 https://wwww.jiataobao.com ,那麼瀏覽器將會檢驗到這個假淘寶釣魚網站的非法性，提醒用戶不要繼續訪問！這樣就可以保證了client的所有https訪問都是安全的。
2.2 單向認證雙向認證
何爲SSL/TLS單向認證，雙向認證？
單向認證指的是隻有一個對象校驗對端的證書合法性。
通常都是client來校驗服務器的合法性。那麼client需要一個ca.crt,服務器需要server.crt,server.key
雙向認證指的是相互校驗，服務器需要校驗每個client,client也需要校驗服務器。
server 需要 server.key 、server.crt 、ca.crt
client 需要 client.key 、client.crt 、ca.crt
2.3 證書詳細工作流
圖二 證書詳細工作流
1）申請認證：服務器需自己生成公鑰私鑰對pub_svr & pri_svr，同時根據 pri_svr 生成請求文件 csr,提交給CA，csr中含有公鑰、組織信息、個人信息(域名)等信息。(圖一中server.req就是csr請求文件)
2）審覈信息：CA通過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法，是否擁有域名的所有權等。
3）簽發證書：如信息審覈通過，CA會向申請者簽發認證文件-證書。
證書包含以下信息：申請者公鑰、申請者的組織信息和個人信息、簽發機構 CA的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名。
簽名的產生算法：首先，使用散列函數計算公開的明文信息的信息摘要，然後，採用 CA的私鑰對信息摘要進行加密，密文即簽名。（圖一中生成server.crt）
4）返回證書：client如果請求驗證服務器，服務器需返回證書文件。（圖一中handshake傳回server.crt）
5）client驗證證書：client讀取證書中的相關的明文信息，採用相同的散列函數計算得到信息摘要，然後，利用對應 CA的公鑰解密簽名數據，對比證書的信息摘要，如果一致，則可以確認證書的合法性，即公鑰合法。客戶端然後驗證證書相關的域名信息、有效時間是否吊銷等信息。
客戶端會內置信任CA的證書信息(包含公鑰)，如果CA不被信任，則找不到對應 CA的證書，證書也會被判定非法。(圖一中check可選，我們可以選擇不驗證服務器證書的有效性)
6）祕鑰協商：驗證通過後，Server和Client將進行祕鑰協商。接下來Server和Client會採用對稱祕鑰加密。(對稱加密時間性能優)（圖一中 pre-master/change_cipher_spec/encrypted_handshake_message過程）
7）數據傳輸：Server和Client採用對稱祕鑰加密解密數據。
2.4 SSL/TLS單向認證流程
---------------------
(1)client_hello
客戶端發起請求，以明文傳輸請求信息，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機數，擴展字段等信息，相關信息如下：
支持的最高TSL協議版本version，從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，當前基本不再使用低於 TLSv1 的版本;
客戶端支持的加密套件 cipher suites 列表， 每個加密套件對應前面 TLS 原理中的四個功能的組合：認證算法 Au (身份驗證)、密鑰交換算法 KeyExchange(密鑰協商)、對稱加密算法 Enc (信息加密)和信息摘要 Mac(完整性校驗);
支持的壓縮算法 compression methods 列表，用於後續的信息壓縮傳輸;
隨機數 random_C，用於後續的密鑰的生成;
擴展字段 extensions，支持協議與算法的相關參數以及其它輔助信息等，常見的 SNI 就屬於擴展字段，後續單獨討論該字段作用。
(2).server_hello+server_certificate+sever_hello_done
server_hello, 服務端返回協商的信息結果，包括選擇使用的協議版本 version，選擇的加密套件 cipher suite，選擇的壓縮算法 compression method、隨機數 random_S 等，其中隨機數用於後續的密鑰協商;
server_certificates, 服務器端配置對應的證書鏈，用於身份驗證與密鑰交換;
server_hello_done，通知客戶端 server_hello 信息發送結束;
(3).證書校驗
[證書鏈]的可信性 trusted certificate path，方法如前文所述;
證書是否吊銷 revocation，有兩類方式離線 CRL 與在線 OCSP，不同的客戶端行爲會不同;
有效期 expiry date，證書是否在有效時間範圍;
域名 domain，覈查證書域名是否與當前的訪問域名匹配，匹配規則後續分析;
(4).client_key_exchange+change_cipher_spec+encrypted_handshake_message
client_key_exchange，合法性驗證通過之後，客戶端計算產生隨機數字 Pre-master，並用證書公鑰加密，發送給服務器;
此時客戶端已經獲取全部的計算協商密鑰需要的信息：兩個明文隨機數 random_C 和 random_S 與自己計算產生的 Pre-master，計算得到協商密鑰;
enc_key=Fuc(random_C, random_S, Pre-Master)
change_cipher_spec，客戶端通知服務器後續的通信都採用協商的通信密鑰和加密算法進行加密通信;
encrypted_handshake_message，結合之前所有通信參數的 hash 值與其它相關信息生成一段數據，採用協商密鑰 session secret 與算法進行加密，然後發送給服務器用於數據與握手驗證;
(5).change_cipher_spec+encrypted_handshake_message
服務器用私鑰解密加密的 Pre-master 數據，基於之前交換的兩個明文隨機數 random_C 和 random_S，計算得到協商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master);
計算之前所有接收信息的 hash 值，然後解密客戶端發送的 encrypted_handshake_message，驗證數據和密鑰正確性;
change_cipher_spec, 驗證通過之後，服務器同樣發送 change_cipher_spec 以告知客戶端後續的通信都採用協商的密鑰與算法進行加密通信;
encrypted_handshake_message, 服務器也結合所有當前的通信參數信息生成一段數據並採用協商密鑰 session secret 與算法加密併發送到客戶端;
(6).握手結束
客戶端計算所有接收信息的 hash 值，並採用協商密鑰解密 encrypted_handshake_message，驗證服務器發送的數據和密鑰，驗證通過則握手完成;
(7).加密通信
開始使用協商密鑰與算法進行加密通信。
2.5 實際wireshark分析
我們搭建的SSL/TLS服務器是192.168.111.100,client是192.168.111.101. client 需要認證 server的合法性。
我們只看 TLSv1.1 的數據包：
第一包(No. 25) Client Hello 包，即SSL/TLS單向認證流程的(1)
第二包(No. 27) Server Hello 包，包含服務器證書等。即SSL/TLS單向認證流程的(2)
第三包(No. 28) 服務器證書驗證完成，同時發送client key exchange+change cipher spec + encrypted handshake message.即SSL/TLS單向認證流程的(4)
第四包(No. 29)祕鑰協商，change cipher spec + encrypted hanshake message.即SSL/TLS單向認證流程的(5)
第五包(No. 30)握手完成。開始上層數據傳輸。SSL/TLS單向認證流程的(7)
2.6 SSL/TLS雙向認證流程
和單向認證幾乎一樣，只是在client認證完服務器證書後，client會將自己的證書client.crt傳給服務器。服務器驗證通過後，開始祕鑰協商。
實際wireshark分析：
和單向認證一樣:
我們搭建的SSL/TLS服務器是192.168.111.100,client是192.168.111.101. client 需要認證 server的合法性，server也需要認證client的合法性！
我們只看 TLSv1.1 的數據包：
第一包(No. 55) Client Hello 包，即SSL/TLS單向認證流程的(1)
第二包(No. 57) Server Hello 包，包含服務器證書等。即SSL/TLS單向認證流程的(2)
第三包(No. 60) 服務器證書驗證完成，同時發送客戶端的證書client.crt ,同時包含client key exchange+change cipher spec + encrypted handshake message.即SSL/TLS單向認證流程的(4)
第四包(No. 61)服務器驗證客戶端證書的合法性。通過後進行祕鑰協商，change cipher spec + encrypted hanshake message.即SSL/TLS單向認證流程的(5)
重傳包(No. 62)由於網絡原因，TCP重傳第No. 60包。
第五包(No. 64)握手完成。開始上層數據傳輸。SSL/TLS單向認證流程的(7)
2.7 證書等格式說明
crt/key/req/csr/pem/der等拓展名都是什麼東東？
1) .crt 表示證書, .key表示私鑰, .req 表示請求文件,.csr也表示請求文件, .pem表示pem格式，.der表示der格式。
文件拓展名你可以隨便命名。只是爲了理解需要而命名不同的拓展名。但文件中的信息是有格式的，和exe，PE格式一樣,證書有兩種格式。
pem格式和der格式。所有證書，私鑰等都可以是pem,也可以是der格式，取決於應用需要。
pem和der格式可以互轉:
openssl x509 -in ca.crt -outform DER -out ca.der //pem -> der
openssl x509 -inform der -in ca.der -out ca.pem // der -> pem
證書轉成p12格式的
openssl pkcs12 -export -clcerts -in ca.crt -inkey ca.key -out ca.p12
pem格式：經過加密的文本文件，一般有下面幾種開頭結尾：
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
or:
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
or:
----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
der格式: 經過加密的二進制文件。
2) 證書中含有 申請者公鑰、申請者的組織信息和個人信息、簽發機構 CA的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名。如查看百度證書詳細信息。
a) 先下載百度證書
火狐瀏覽器訪問https://www.baidu.com/, 點擊左上角綠色小鎖，點擊向右箭頭，點擊更多信息，點擊查看證書，點擊詳細信息，點擊導出。即可導出百度的證書 baiducom.crt
b) 命令查看證書詳細信息
openssl x509 -noout -text -in baiducom.crt
詳細信息中，有一個字段： X509v3 Basic Constraints: CA: FALSE
該字段指出該證書是否是 CA證書，還是一般性的非 CA 證書。詳細描述見 RFC5280#section-4.2.1.9，同時 RFC5280 也詳細描述證書工作方式等。
3) 私鑰加密，公鑰解密！
2.8 SSL/TLS和 Openssl,mbedtls是什麼關係？
SSL/TLS是一種工作原理，openssl和mbedtls是SSL/TLS的具體實現，很類似於 TCP/IP協議和socket之間的關係。
三: 本地生成SSL相關文件
3.1 證書生成腳本
我們自己本地使用 makefile.sh 腳本建立一個CA(ca.crt + ca.key)，用這個CA給server和client分別頒發證書。
makefile.sh
# * Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# * Neither the name of the axTLS project nor the names of its
# contributors may be used to endorse or promote products derived
# from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
# TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
# OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
# NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
# THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
#
# Generate the certificates and keys for testing.
#
PROJECT_NAME="TLS Project"
# Generate the openssl configuration files.
cat > ca_cert.conf << EOF
[ req ]
distinguished_name = req_distinguished_name
prompt = no
[ req_distinguished_name ]
O = $PROJECT_NAME Dodgy Certificate Authority
EOF
cat > server_cert.conf << EOF
[ req ]
distinguished_name = req_distinguished_name
prompt = no
[ req_distinguished_name ]
O = $PROJECT_NAME
CN = 192.168.111.100
EOF
cat > client_cert.conf << EOF
[ req ]
distinguished_name = req_distinguished_name
prompt = no
[ req_distinguished_name ]
O = $PROJECT_NAME Device Certificate
CN = 192.168.111.101
EOF
mkdir ca
mkdir server
mkdir client
mkdir certDER
# private key generation
openssl genrsa -out ca.key 1024
openssl genrsa -out server.key 1024
openssl genrsa -out client.key 1024
# cert requests
openssl req -out ca.req -key ca.key -new \
-config ./ca_cert.conf
openssl req -out server.req -key server.key -new \
-config ./server_cert.conf
openssl req -out client.req -key client.key -new \
-config ./client_cert.conf
# generate the actual certs.
openssl x509 -req -in ca.req -out ca.crt \
-sha1 -days 5000 -signkey ca.key
openssl x509 -req -in server.req -out server.crt \
-sha1 -CAcreateserial -days 5000 \
-CA ca.crt -CAkey ca.key
openssl x509 -req -in client.req -out client.crt \
-sha1 -CAcreateserial -days 5000 \
-CA ca.crt -CAkey ca.key
openssl x509 -in ca.crt -outform DER -out ca.der
openssl x509 -in server.crt -outform DER -out server.der
openssl x509 -in client.crt -outform DER -out client.der
mv ca.crt ca.key ca/
mv server.crt server.key server/
mv client.crt client.key client/
mv ca.der server.der client.der certDER/
rm *.conf
rm *.req
rm *.srl
將上述代碼保存爲makefile.sh
做如下修改，終端執行。
- 修改 CN 域中 IP 地址爲你主機/設備的 IP 地址
- [可選]加密位數 1024 修改爲你需要的加密位數
將會看到：
ca目錄：保存ca的私鑰ca.key和證書ca.crt
certDER目錄:將證書保存爲二進制文件 ca.der client.der server.der
client目錄: client.crt client.key
server目錄:server.crt server.key
3.2 刪除腳本
$./makefile.sh
刪除腳本rmfile.sh:
rm ca/ -rf
rm certDER/ -rf
rm client/ -rf
rm server/ -rf
將上述代碼保存爲rmfile.sh,終端執行，將會刪除產生過的目錄和文件：
$./rmfile.sh
3.3 CA校驗證書測試
我們可在本地使用 CA證書來分別校驗由自己頒發的服務器證書 server.crt 和客戶端證書 client.crt .
$openssl verify -CAfile ca/ca.crt server/server.crt
$openssl verify -CAfile ca/ca.crt client/client.crt