PostgreSQL 连接是否要通过SSL，为什么使用SSL 连接后，业务部门会投诉我？

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，（共1680人左右 1 + 2 + 3 + 4） 3群突破 490已关闭自由申请如需加入请提前说明，新人会进4群（200+）准备开5群,另欢迎 OpenGauss GAUSSDB的技术人员加入。

每日感悟

朋友走着走着就散了，可惜吗。谈不上一辈子你如火车，朋友如一段平行的列车，千万不要交汇点，有利益的冲突，那必然是车毁人亡，大部分时间人生的轨道上，只有你自己在上面飞奔，习惯就好。

相信使用数据库的同学，对于SSL这名词并不陌生，但问及SSL的数据库连接的访问的方式是否应该被用在数据库上面，这点可能知道的人就不多了，用了怎么样，不用又会怎么样。咱们的说一说，SSL安全套接字，安全套接字是一种加密的安全协议，1995由netscape发明，确保通信中的信息的隐私性和身份验证性等。SSL 本身在两个通信设备之间启动成为握手验证，确保两个设备确认他们所定义的身份，同时SSL还对数据进行数字签名验证数据是否到达目标接手者之前是否篡改过。

对于数据产品本身经过在这么多年的数据库使用中，并未有通过SSL协议来进行数据访问的使用经验，为什么有如下的一些问题需要进行解决。

1  什么时候应该使用SSL

这是一个好的问题，在多种的专业资料中都提到SSL对于数据库的必要性保证数据和应用端使用数据的信息安全，防止数据被盗取等问题。防止黑客对数据库数据进行访问或截取网络的数据包等问题，导致数据被盗取。但是SSL 协议以及相关的使用者从未说明这些SSL的使用的领域是在数据库被放置在公网的领域里面。

为什么基于SSL协议本身的一些问题，SSL对于数据库的性能损耗一直是一个被数据库工作者关心的问题，这正如你如果要横跨告诉公路，一定不能从告诉公路中横跨，但如果你仅仅是在你家小区横跨以下也要建立一个人行天桥就未免有些不能被理解了。

在一些安全的材料中，也提到SSL 的必要性，但专业的材料中也基本会提到，Unless the database server and the client are communicating over a local network. 这里大致的意思是SSL非常重要，除非你是在本地网络进行数据的访问，也就是你的应用和数据库都在一个网络内，在一个本地区域的网络内，这样就没有必要进行SSL 的使用。

为什么，他们要提及这句话，实际上SSL的使用是有很大的成本的，这里简单的描述SSL 访问的过程，这里 A 与 B 进行访问，则A 和 B 都需要选定加密的算法，通过确认饱含公钥的证书，并且双方 都要进行会话秘钥的产生和确认并且进行握手。简单的总结为5部分

1 client hello

2  server hello

3  certificate server key exchange , server hello done

4  client key exchange ,change cipher spec ,encrypted handshake message

5  change cipher spec, encrypted handshake message

也就是如果你想进行一次客户端和数据库之间的访问，要走5步后才能正常 进行数据的传输。相对于TCP/IP的协议，3步走，还要多两步。

所以我们必然考虑一件事情，在采用SSL 后对于数据库的性能下降我们是否能接受，正好我们最近做了一次PG的数据库在不采用SSL 和采用SSL协议后的数据的使用中的性能变化，我们简单列一个表。

基于下面的表中的测试数据，我们可以看到在相关的测试中，只要通过SSL 访问的方式中对比采用普通方式访问的情况下，必然出现性能的损耗，损耗的差异与表的大小 ，以及并发等都有关。

编号	数据库开启SSL/TPS	数据库关闭SSL/TPS	性能损耗	客户端模拟数量	应用线程数据量	数据操作方式	表数量	表行数	测试时间	说明
编号	数据库开启SSL/TPS	数据库关闭SSL/TPS	性能损耗	客户端模拟数量	应用线程数据量	数据操作方式	表数量	表行数	测试时间	说明
1	15201	17861	2660 TPS	100	4	update	100	100万	180S
2	14658	17659	3001 TPS	100	4	update	100	100万	300S
3	14733	17870	3137 TPS	100	4	update	100	1000万	180S
4	14852	18049	3197 TPS	100	4	update	100	1000万	300S
5	12249	14717	2468 TPS	100	4	update + select	100	100万	180S
6	12501	14449	1948 TPS	100	4	update + select	100	100万	300S
7	12628	15440	2812 TPS	100	4	update + select	100	1000万	180S
8	12526	14527	2001 TPS	100	4	update + select	100	1000万	300S

基于相关的测试中的结果，在内网中对于POSTGRESQL 访问建议不启用SSL 的访问方式，而是采用其他的方式来进行核心数据的安全防护。

这里有以下的一些建议

1   在内网访问中，关于核心的表的核心字段进行字段加密，在数据写入到数据列中的数据为已经加密好的数据，读取数据解密也在应用程序中进行，尽量将对数据库产生可能的压力，分解到应用服务器中。

2   如果必须在数据库中进行加密则使用POSTGRESQL 扩展pgcrypto 来进行相关的工作。

但如果数据库是放到外网中，则需要更多的手段来进行安全防护，这里就不过多的进行叙述了。