关于ssl:分布式-如何与-DBLE-进行秘密通话

作者：蔡玮

中间件 dble 测试成员，次要负责 dble 的日常测试工作，热衷于摸索发现，学习新技术。

本文起源：原创投稿

* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。

SSL 协定简介

家喻户晓，如果咱们在网络上传输数据时信息都是应用明文的话，会很容易呈现数据被监听和窃取的状况，从而造成肯定的安全性的问题，这对于一些集体敏感信息乃至公司的数据安全无疑造成了很大的危险。

基于此，势必有肯定的需要，对网络上传输的数据进行“包裹化”解决，而 SSL 即在此背景之下应运而生。Netscape 公司于 1996 年提出了平安协定 SSL，其是工作于应用层和传输层之间的一款协定，设计即全面，其波及的概念泛滥，不仅仅“包裹化”数据【数据加密】，更是提供了身份验证和音讯完整性验证机制，为网络数据传输安全性建设做出了巨大贡献，从而十分大程度上改善了互联网的安全性问题。

对于数据库层面，加密通信同样显得很重要，毕竟任何业务的数据存储最终都要落实到数据库上，其重要性显而易见。所以对于 MySQL 而言，SSL 曾经是一个成熟的性能并广泛应用。对于协定实现原理以及加密算法不再是本文介绍的重点，在此就不再赘述，可参考历史公众号文章：MySQL : SSL 连贯浅析

SSL 之 DBLE 篇

概述

作为一款数据库中间件产品，在应用 DBLE 时，将 MySQL 挂载到 DBLE 后端后，齐全能够脱离 MySQL 而与 DBLE 进行间接建设连贯。那么问题来了，如何确保与 DBLE 进行通信时数据的安全性呢？显然，在这方面 DBLE 须要向 MySQL 学习，应用 SSL 武装本人，以确保通信时用户数据的安全性。

在行将要发版的 DBLE 版本中，咱们将会反对 SSL 加密连贯，须要留神的是目前加密解决是处于 Client — DBLE 通信阶段，DBLE — MySQL 通信阶段暂未波及。同时在曾经发版的 DBLE 3.22.01.1 的小版本中也已率先反对了 SSL，感兴趣的同学能够下载相干的版本进行试用。

应用阐明

对于 DBLE 的 SSL 连贯配置和 MySQL 有肯定的相似性，然而并不尽相同，上面就 DBLE 对于 SSL 加密的应用进行简要的配置应用介绍。

相熟 SSL 的同学应该晓得，应用 SSL 的前提必然是各种证书【波及各种密钥信息】，DBLE 也并不例外。MySQL 中应用的是自签名证书，自签名证书是由不受信的 CA 机构颁发的数字证书，也就是本人签发的证书。与受信赖的 CA 签发的传统数字证书不同，自签名证书是由一些公司或软件开发商创立、颁发和签名的。DBLE 同样采纳和 MySQL 一样的形式：应用自签名证书形式制作 SSL 证书。

证书制作

证书制作须要借助 OpenSSL 来进行，如果机器上并未装置可手动进行装置 OpenSSL。

1、制作 CA 自签名证书 (蕴含公钥) 和私钥

openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 3600 -key ca-key.pem -out ca.pem

2、创立私钥和签发服务端的数字证书

openssl req -newkey rsa:2048 -days 3600 -nodes -keyout server-key.pem -out server-req.pem
openssl rsa -in server-key.pem -out server-key.pem
openssl x509 -req -in server-req.pem -days 3600 -CA ca.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem

3、创立私钥和签发客户端的数字证书（与上类似）

openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem -out client-req.pem
openssl rsa -in client-key.pem -out client-key.pem
openssl x509 -req -in client-req.pem -days 3600 -CA ca.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem

4、验证服务端和客户端数字证书是否可信，当输入的后果为 OK，示意通过

openssl verify -CAfile ca.pem server-cert.pem client-cert.pem

值得一提的是，MySQL 自带一键生成证书的 mysql_ssl_rsa_setup 命令中外部也是大抵依照以上生成证书的，所以更不便的做法是间接应用 mysql_ssl_rsa_setup 生成相应的证书文件【当然用于 DBLE 处也须要再进行证书类型转换，见下文】。

证书类型转换

因为 DBLE 是基于 JAVA 语言进行开发的，OpenSSL 生成的证书格局 pem、crt 等格局，在 JAVA 语言并不能正确辨认，须要额定应用 keytool 工具【java 原生自带，装置 java 后不须要再进行装置】转换成 p12、jks 格局，同时如果应用的客户端是 JDBC 时，相干的 URL 中用到的证书也须要应用格局转换后的证书文件，其余 Driver 则均实用于 pem 证书文件。

1、将 ca.pem 导入 Java 平台的密钥库中，java 反对密钥库类型有：JKS、JCEKS、PKCS12、PKCS11 和 DKS，这里生成 JKS 扩展名的 truststore.jks 密钥库，明码可自定义，此处定义为 123456

keytool -import -noprompt -file ca.pem -keystore truststore.jks -storepass 123456

2、将 server-cert.pem 和 server-key.pem 转成 p12 类型的密钥库，而后在转成 JKS 类型的密钥库，明码可自定义，此处定义为 123456

openssl pkcs12 -export -in server-cert.pem -inkey server-key.pem -out serverkeystore.p12 -passout pass:123456
keytool -importkeystore -srckeystore serverkeystore.p12 -srcstoretype PKCS12 -destkeystore serverkeystore.jks -srcstorepass 123456 -deststorepass 123456

3、同样，将客户端用到的证书文件转换为 JKS 类型的密钥库，明码可自定义，此处定义为 123456

openssl pkcs12 -export -in client-cert.pem -inkey client-key.pem -out clientkeystore.p12 -passout pass:123456
keytool -importkeystore -srckeystore clientkeystore.p12 -srcstoretype PKCS12 -destkeystore clientkeystore.jks -srcstorepass 123456 -deststorepass 123456

至此，咱们一共失去了以下密钥文件信息:

服务端 DBLE 配置

服务端 DBLE 配置

在应用 SSL 时，DBLE 作为服务端须要手动进行配置相干的文件信息，并开启相干的性能。和 MySQL 统一，咱们提供了一个开关 supportSSL，用于标识 SSL 是否启用，默认值为 false，如果须要应用 SSL 连贯时，首先须要确保此开关处于关上的状态。同时须要配置应用到的一些证书信息，在 bootstrap.cnf 中进行如下配置：

-DsupportSSL=true
-DserverCertificateKeyStoreUrl=${path}/serverkeystore.jks
-DserverCertificateKeyStorePwd=123456
-DtrustCertificateKeyStoreUrl=${path}/truststore.jks
-DtrustCertificateKeyStorePwd=123456

配置实现之后，重启 dble 即可。

为了便于查问 SSL 的一些状态信息，咱们在 DBLE 的治理端 dble_information 库中新增了一些用于保护相干的 SSL 的元数据信息，确保配置无误并重启 dble 之后，可在 DBLE 治理端查问到对应的 SSL 配置信息以及状态：

客户端连贯配置

在应用 SSL 连贯 MySQL 时辨别了多种连贯模式，此形式同样实用于 DBLE，以下提供两种常见的 Client 加密连贯时的客户端配置:

试验

disabled 模式

在应用 SSL 加密连贯 DBLE 之前，让咱们先借助抓包工具 wireshark 来看看未应用加密连贯 DBLE 时，数据传输是怎么样的。在这里应用 JDBC 作为客户端为例。在进行查问之前，笔者已后行依照上述步骤在 DBLE 侧配置并开启了 SSL，创立好了 user 表，并筹备了相干的数据，在此不作为重点进行赘述。

1、非加密连贯 DBLE，以下为 JDBC Demo 可供参考，与 DBLE 建设连贯并查问 user 表数据：

public class SslTest {

    private static final String JDBC_DRIVER = "com.mysql.jdbc.Driver";

    public static void main(String[] args) throws SQLException, IOException, ClassNotFoundException {List<User> res = disabled();
        System.out.println(res);
    }

    public static List<User> disabled() throws ClassNotFoundException, IOException, SQLException {List<User> usersList = new ArrayList<>();
        Properties pro = new Properties();
        FileInputStream fis = new FileInputStream("E:\\jdbc\\src\\main\\resources\\dble.properties");
        pro.load(fis);

        Class.forName(JDBC_DRIVER);
        String url = "jdbc:mysql://" + pro.getProperty("host") + ":" + pro.getProperty("port") + "/" + pro.getProperty("db");
        String fullUrlString = url + "?useSSL=false";    // 非加密连贯

        Connection conn = DriverManager.getConnection(fullUrlString, pro.getProperty("user"), pro.getProperty("password"));
        PreparedStatement ps = conn.prepareStatement("select username from user");
        ResultSet rs = ps.executeQuery();
        while(rs.next()){String name = rs.getString("username");
            usersList.add(new User(name));
        }
        ps.close();
        rs.close();
        conn.close();
        return usersList;
    }
}

2、开启抓包后，执行相干 demo 进行查问，将数据包过滤、解析后如下所示：

能够发现，传输的数据包含登录信息、SQL 以及返回的数据信息，都是可能透过 wireshark 通过解析后能够以明文的信息查问到。

required 模式

在此仅以某一种 SSL 加密模式为例进行测试演示——required，在以上的 JDBC Demo 中稍加批改，将 URL 参数变更为相应的模式参数【如下所示】，即可进行加密通信：

String fullUrlString = url
+ "?useSSL=true&requireSSL=true&verifyServerCertificate=false";

而后再次抓包并执行 Demo 进行查问，解析数据包并过滤失去：

能够发现在建设 TCP 连贯之后，SSL 协定随之进行单方的认证过程，具体协定剖析可参考：https://www.jianshu.com/p/802…，通过认证之后，随即以 TLS 加密协议的规范将数据包进行加密后传输，即使通过初步的解析后也无奈失去传输的数据信息，最终确保了数据的安全性。当然，如果咱们有服务端的 SSL 密钥文件，在 wireshark SSL 协定设置中增加相干的密钥信息，也是能够胜利解析出传输的具体数据包信息的，在此不再过多演示，感兴趣的读者可自行测试。

总结

凡事都有两面性，加密连贯尽管确保了数据的安全性，然而另一方面无疑是就义了局部性能。从 SSL 实现形式来看，建设连贯时须要进行握手、加密、解密等操作。所以耗时根本都在建设连贯的阶段，这对于应用短连贯的应用程序可能并不太敌对，因为会产生较大的性能损耗。不过对于应用连接池或者长连贯的应用程序可能会好许多。所以，对于要求高性能的利用，或者不产生外围敏感数据的利用，性能及可用性才是首要，倡议不要采纳 SSL 形式。

同时须要留神区别的是，DBLE 侧在进行 SSL 设置时，并没有像 MySQL 一样设置了【require_secure_transport】相似的强制要求应用平安连贯参数设置，也没有依照用户去辨别 SSL 配置的实用对象，只有 DBLE 服务端开启并正确配置了 SSL 选项，所有用户与 DBLE 建设连贯时均可自主抉择是否须要采纳 SSL 加密连贯。