如何理解MySQL的SSL連接
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證書頒發給客戶端的證書和私鑰進行來連接?？蛻舳艘话悴恍枰峁〤A證書，除非客戶端加了需要驗證服務端的有效性，也就是雙向認證。
服務端的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，水平有限，如發現有理解偏差，歡迎留言指正。
