SSL在HTTPS和MySQL中的原理思考

2020-06-16 17:35:08

之前對HTTPS通訊過程有過了解，HTTPS是應用HTTP協定使用SSL加密的版本，在TCP和HTTP之間增加SSL協定。通過握手階段認證雙方身份，協商對稱秘鑰對通訊資訊進行加密。此處只描述常用的伺服器單向驗證，大致過程簡要描述如下：

0：事先Web伺服器把自己的公鑰和Web資訊提交給權威CA，CA確認後，用自己的私鑰將Web資訊以及公鑰的文摘簽名，製成數位憑證交給Web伺服器；

用戶端Web瀏覽器事先安裝被信任的權威CA的根證書（未簽名證書或者自簽名證書）

1：用戶端向伺服器發起連線請求，協商使用的SSL版本、非對稱加密演算法、對稱加密演算法以及摘要生成演算法，雙方達成共識

2：Web伺服器向用戶端傳送自己的數位憑證，用戶端用CA的根證書解密，證明Web伺服器身份真實，同時證明伺服器公鑰正確

3：用戶端用伺服器公鑰加密一個亂數，作為通訊收發資料的對稱秘鑰，傳送給伺服器

4：伺服器用自己的私鑰解密，拿到對稱秘鑰，返回ACK

5：用戶端和伺服器使用對稱秘鑰開始通訊

到學習MySQL的SSL連線設定時產生一個疑問，HTTPS有CA作為可信第三方，負責確認伺服器身份，而MySQL連線通訊只2方，沒聽說還有個CA從中協調啊，那還怎麼SSL啊？

通過網上查資料，發現自己對SSL相關的很多概念理解不是很準確，對之前CA的驗證方式理解不對。首先明確一些概念：

公私鑰對：非對稱加密演算法，公鑰和私鑰成對出現，用公鑰加密用私鑰解密，用私鑰加密用公鑰解密

CA：證書頒發機構，通訊雙方可信的第三方。自己有公私鑰對，網站想證明自己真實可信，但使用者不相信自己，只相信CA說的，於是網站提交自己的資訊和公鑰給CA，CA核實網站資訊和提交的公鑰，覺得靠譜，於是簽名，製成證書，交給網站成為一個資質。

簽名：別人不知道我的私鑰，但是知道我的公鑰。怎麼證明這檔案是我認證的呢？我用自己的私鑰加密，別人用我的公鑰解密成功，那肯定知道是我加密的，別人幹不了。具體一點，先對文字內容計算雜湊值，然後對這個雜湊值用自己的私鑰加密。（別人對文字內容計算雜湊值，然後用我的私鑰解密得到的值做對比，一致證明簽名OK）

證書：包含3部分，通訊方具體資訊（地點、域名、組織、擁有者等）、通訊方的公鑰、權威CA的簽名。（具體資訊和公鑰計算雜湊值，然後對這個雜湊值用自己的私鑰加密）

根證書：權威CA也有自己的證書（畢竟需要CA的公鑰來驗證網站證書真偽），那CA的證書誰簽名啊？畢竟沒有更高一級了，所以根證書是未簽名的或者是自簽名的，沒人給這個證書背書了，所以叫做根，是信任鏈的起點，都可以理解了。

再看MySQL的SSL連線設定，思考SSL通訊過程，就可以理解為什麼需要這些檔案了（此處描述SSL單向驗證模式）

MySQL伺服器端要設定3個檔案：ssl-ca.pem, ssl-key.pem, ssl-cert.pem

用戶端連線時需要檔案：ssl-ca.pem

ssl-ca.pem就充當了可信的第三方，CA根證書，檔案裡包含了CA的資訊和公鑰，用戶端和伺服器都有。

1.用戶端向MySQL伺服器發起連線請求，雙方協商加密演算法、SSL版本等

2.伺服器向用戶端發來自己的證書（ssl-cert.pem的內容，CA簽名的），用戶端用ssl-ca.pem的公鑰解密，確認伺服器身份和公鑰真實。

3.用戶端產生亂數作為對稱加密的秘鑰，用伺服器公鑰加密，傳送給伺服器

4.伺服器用自己的私鑰（ssl-key.pem）解密，拿到這個亂數，返回ACK

5.雙方用亂數做金鑰，以對稱加密方式通訊

舉一反三，其他應用層協定使用SSL通訊時，也是一樣的套路了。如果有哪些地方不準確，請留言指正，感謝。