如何理解MySQL的SSL连接

[[205062]]

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认为是合法的才有后续的协商。

[[205064]]

加解密流程比较复杂，不需要太精通，就知道可以合法情况下可以正常加解密正常流转就好了。

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，水平有限，如发现有理解偏差，欢迎留言指正。