为什么在商密系统中，内网应用需要使用密码设备做https代理才是合规的？

最新推荐文章于 2024-01-07 11:15:53 发布

walle2.2

最新推荐文章于 2024-01-07 11:15:53 发布

阅读量1.1k

点赞数 5

分类专栏：基础文章标签： https 网络 ssl

本文链接：https://blog.csdn.net/weixin_44535758/article/details/127864702

版权

基础专栏收录该内容

20 篇文章 6 订阅

订阅专栏

某政务信息化指南中的拓扑图

相信但凡有点网络常识的，看到这个图都会有点疑惑，为什么在内网中使用多台VPN网关呢，在网络出口处放一台不就够了吗？VPN网关不是用来做远程访问的吗？

经过个人不断钻研，最终终于搞明白了，同时也感叹中国的密码之路也是路漫漫其修远兮·~

下面跟大家分享一下我的理解，不一定对，仅代表个人观点！
首先提几个问题：
1、在SSL的三次握手中，你知道现在主流的密码套件是什么吗？
2、你了解我国PKI双证书的机制吗，你知道国家为什么要上双证书吗？
3、在TLS握手过程中，RSA、ECDHE密钥协商协议的原理是什么？

如果你能搞懂这几个问题，那么，商密系统中，为什么要用密码设备做HTTPS做代理你也就明白了。
下面为大家逐一解答这三个问题

问题一：在SSL的三次握手中，你知道现在主流的密码套件是什么吗？

咱们直接抓百度的包来看
抓包截图
可以看到，这里使用的密码套件为：TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

密钥协商算法使用 ECDHE；
签名算法使用 RSA；
握手后的通信使用 AES 对称算法，密钥长度 128 位，分组模式是 GCM；
摘要算法使用 SHA256

第一个问题解答结束！下面开始解答第二个问题！

问题二：我国的PKI双证书机制是怎样的？为什么要使用双证书？

双证书：加密证书，签名证书，也就是说在用户那里有2对密钥，一对是签名密钥，一对是加密密钥，签名密钥对是用户自己产生的、加密密钥对是通过CA认证中心向KMC申请的。

KMC：密钥管理中心；负责密钥管理的机构；国家机构

由于加密的密钥对是由KMC产生并给到用户的，所以用户的机密性并不由用户自己单独享有，国家进行监管，方便特殊情况的取证。

这里给大家拓展一下，带大家了解一下国密的算法套件、怎么分辨签名证书、加密证书！

抓包国密ssl握手包看一下：
在这里插入图片描述
密码套件: ECC_SM4_SM3

密钥协商算法使用SM2；
签名算法使用SM2；
握手后的通信使用SM4加密对称密码；
摘要算法使用SM3；

标准GM/T 0024-2014中规定实现ECC和ECDHE的算法为SM2
密码套件的基本形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」，这里明显是密钥协商和签名都使用的SM2

如何区分签名证书和加密证书呢？

通过看证书拓展信息，keyUsage，密钥用法的参数即可辨别，上图为签名证书

通过看证书的拓展信息，可以知道上图的证书是加密证书
在这里插入图片描述

GM/T 0024-2014 SSL VPN 技术规范

这是第二个问题的解答、相信你还没搞明白为什么商密系统要使用密码设备代理https才是合规的，不要着急，现在解答第三个问题，相信你听完第三个问题解答就明白了，甚至会有豁然开朗的感脚！

问题三：在TLS握手过程中，RSA、ECDHE密钥协商协议的原理是什么？

RSA：https://mp.weixin.qq.com/s/U9SRLE7jZTB6lUZ6c8gTKg
ECDHE：https://www.cnblogs.com/xiaolincoding/p/14318338.html
具体看链接的内容吧，写的很详细，我就不重复写了

总结一下

目前主流的国密SSL算法套件为ECC_SM4_SM3 ECDHE_SM4_SM3
注意，ECDHE_SM4_SM3 必须要求双向认证。
ECC也就是SM2，其实是对标的RSA，客户端先生成预主密钥，加密发给服务端，服务端解密，拿来生成会话密钥，
之所以使用预主密钥、主密钥、会话密钥，主要是服务端不信任客户端随机数的随机性，通过叠加的方式，来保证随机性
在这里插入图片描述

在这里插入图片描述

这个消息是用加密证书中的公钥加密，那么服务端收到这个消息，需要使用自己的加密密钥对的私钥进行解密。
那么就要求服务端要保存私钥，这就会存在前向安全性的问题，那么我们用一台密码设备做https代理，私钥保存在密码设备中，这样就保证了这个密钥的安全性了。这也就是为什么，商密的信息系统为什么要使用密码设备做https的代理，就是因为这个私钥的存在。
那么对于ECDHE来说，如果看过上面的文章可以知道，它的密钥对都是临时生成的，不存在前向安全性，而且服务端本身的证书和与之对应的私钥，主要是用来签名和验签，这也是单证书的PKI体系。
在这里插入图片描述

个人感觉，现在用的比较多的单证书体系，使用ECDHE进行密钥协商，并不存在什么问题，服务端即便存了私钥和证书，这个私钥主要用来签名，发给客户端，客户端先验证服务端发来的证书，证书没有问题，再验证签名，验签成功，也能说明证书跟证书持有者的绑定关系。主要还是不适用咱们国家对机密性的管控要求。

对于国密的这个ECDHE密钥协商，个人感觉也是做了改造，客户端和服务端都需要持有2对密钥，签名密钥对和加密密钥对，然后在协商的过程中再产生临时密钥对，这就要求，客户端那边也要有合规的密码设备来存放这个密钥对，比如智能密钥钥匙。
这种可以用于双向鉴别，像ECC密钥协商，这种比较简单，只需要服务端存私钥就好了，客户端生成的预主密钥是临时生成的。
当然了，使用ECC算法进行密钥协商也可以实现双向鉴别。这样看国密ECDHE密钥协商算法对于SSL握手协议来说就比较鸡肋了，个人理解，如果不正确，还请多多指正！
在这里插入图片描述