1. 概述

不僅僅是https站點，ssl連線在各個方面都慢慢流行起來了，像mysql5.7以後預設就開啟了ssl連線，這篇文章主要介紹下mysql在ssl加密連線的情況下發生了哪些事情和怎麼來解密ssl加密的mysql流量，以及一些對ssl連線的疑問解答。

2. 服務端配置

1. mysql進行ssl配置時候，需要一個CA和CA用服務端的key頒發給服務端的證書，分別是ssl_ca ssl_key ssl_cert 這三個引數值。 也就是show variables like ‘%ssl%’;看到的結果，詳情略。

2. 進行使用者配置，在grant授權時候需要在最後加上require X509;值。

3. 製作證書：

一般我們的CA是本機，然後進行自頒發證書，比如以前講到過的教程，CA簡單搭建：

cd /etc/pki/CA 
(umask 077; openssl genrsa 2048 > private/cakey.pem) 
openssl req -new -x509 -key private/cakey.pem  -out cacert.pem -days 3650     #x509
touch index.txt     #證書索引
echo 01 > serial     #當前所發證書的序列號，從01開始

CA頒發mysql服務端證書：

mkdir -p /data/ssl && cd /data/ssl
(umask 077;openssl genrsa 2048 > master.key)
openssl req -new -key master.key -out master.csr -days 3650 
openssl ca -in master.csr -out master.crt -days 3650 
chown -R mysql:mysql  master*
 

上述證書配置在my.cnf裡面。

CA頒發mysql客戶端證書：

mkdir -p /data/ssl_slave && cd /data/ssl_slave
(umask 077;openssl genrsa 2048 > slave.key)
openssl req -new -key slave.key -out slave.csr -days 3650 
openssl ca -in slave.csr -out slave.crt -days 3650 
chown -R mysql:mysql  slave*

上述證書複製給客戶端機器備用。

3. 客戶端

連線命令：

mysql -h127.0.0.1 -P3306 --ssl-cert=/data/ssl/slave.crt --ssl-key=/data/ssl/slave.key

這樣指定由服務端指定的CA證書頒發給客戶端的證書和私鑰進行來連線。客戶端一般不需要提供CA證書，除非客戶端加了需要驗證服務端的有效性，也就是雙向認證。

服務端的CA證書可以頒發很多證書給客戶端，這裡有個吊銷的概念，CA可以吊銷自己頒發給別人的證書（CRL）。

但是吊銷證書針對我們5.5的版本是不生效的，也就是說給客戶端頒發證書之後，就算你在CA這裡吊銷了，但是客戶端還是可以通過那個證書連過來。這裡chrome也是一樣的，不檢查證書是否被吊銷，費事。

這裡和瀏覽器的https訪問有差異，比如瀏覽器是我們要校驗服務端是否合法，但是mysql連線時候是服務端校驗我們客戶端是否合法，雙向校驗除外。

4. ssl握手簡談

這裡在ssl層會提供些待進行協商的資訊給服務端，比如ssl_cipher加密演算法和某個隨機數，明文傳給服務端，服務端進行協商之後，也產生個隨機數，然後和自己的證書(ssl_cert值)一起傳送給客戶端。 客戶端收到服務端傳送的證書之後，從裡面取出公鑰資訊，然後用這個公鑰加密一個隨機密碼傳送給服務端。由於是服務端的公鑰，服務端收到之後可以用他的私鑰(ssl_key值)進行解密，獲取到這個隨機密碼，然後就用這個密碼進行後續的流量加解密了（這裡的hash校驗就不說了，就是每次收到之後進行個校驗，看是否解密出的資料和加密之前的是一致）。

具體情況有些差異。

客戶端指定自己的私鑰和證書連服務端之後，服務端會用啟動時候載入的ssl_ca值，也就是CA中心來校驗客戶端傳送過來的證書是自己頒發的，如果CA認為是合法的才有後續的協商。

加解密流程比較複雜，不需要太精通，就知道可以合法情況下可以正常加解密正常流轉就好了。

5. 小疑問

1. 服務端用的CA裡面key和證書檔案被別人拿走了，有風險嗎？
   那肯定的，風險莫過於此了，如果是一個CA公司的話，這樣公司可以準備申請破產了。這裡的話簡單說是這樣別人可以用CA頒發可以被服務端信任的證書來連線，也可以做中間人攻擊。
2. 服務端用的證書和私鑰被別人拿走了，有風險嗎？
   那肯定的，也就是說別人可以進行中間人攻擊或者用私鑰進行被加密的流量進行解密，而且無法吊銷此證書(Mysql 5.5)。
3. 服務端的ssl證書可以平滑替換嗎？
   不可以，mysql裡面這個變數是隻讀的，在啟動時候載入，就算後續把證書內容改變了，mysql認的還是啟動時候載入在記憶體裡面的資訊，需要替換的話需要重啟mysql。
4. 客戶端需要用服務端的證書資訊來連線mysql嗎？
   不一定，一般只需要用服務端裡面的CA頒發的任意證書就可以了，除非授權時候有用REQUIRE SUBJECT特意指定SUBJECT的屬性。
5. CA頒發了新的證書給從庫伺服器，只要這個證書不洩露，別人就無法解密我們的加密流量嗎？
   不是的，這個證書只是證明你這個從庫是有效的客戶端，可以用主庫裡面定義的私鑰進行流量解密。
6. 有私鑰就可以解密流量嗎？不一定，看加密演算法，如果不是DH加密演算法，可以解密所有的加密流量，如果是DH之類的加密演算法只可以通過手段解密之後的流量，但不能否認洩漏CA和伺服器證書的風險。
7. 流量解密需要怎麼測試呢配置ssl-cipher加密演算法，去掉DH相關的加密演算法，然後wireshark指定私鑰就可以了，下面附帶個解密加密的mysql流量教程。

6. wireshark流量解密

下面進行ssl解密。

下載mysql服務端的證書私鑰，也就是之前說的master.key檔案，然後開啟wireshark的首選項進行協議配置：

重新開啟會發現多了個Decrypted SSL的選項，也就是ssl解密之後的明文資訊（正式測試時候留意是否存在wireshark的快取導致資料異常）：

sql語句成功讀取了，ssl流量成功解密。

以上測試環境基於Percona-Server-5.5，水平有限，如發現有理解偏差，歡迎留言指正。

原文來自微信公眾號：運維軍團