SSL在https和MySQL中的原理思考

標籤：

之前對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通訊時，也是一樣的套路了。如果有哪些地方不準確，請留言指正，感謝。

 

SSL在https和MySQL中的原理思考