一 背景

随着越来越多的国际通用密码算法屡屡被传出被破解、被攻击的传闻，存在较高的安全风险。此外，当前我国金融系统大多采用国外制定的加密算法，存在着大量的不可控因素，一旦被不法分子利用攻击，所产生的损失将不可估量。所以国密改造提上日程。国密SSL通信依据的协议是中国人民共和国密码行业标准《SSL VPN技术规范GM/T 0024--2014》协议(链接)。其协议流程和传统的使用RSA证书的TLS协议流程基本一致，但是过程中使用的核心算法已经全部切换到国密相关的算法实现上，为了保证通信的安全监管机构开始推动国内金融行业进行国密改造。我们和客户一起进行了多个国密项目的改造之后，这里整理了国密HTTPS 和国密SSL 相关知识，做下分享。

二 国密SSL/TLS

1. HTTPS

首先标准的 HTTPS （Secure Hypertext Transfer Protocol）是由HTTP + SSL/TLS组成的安全超文本传输协议，利用 SSL/TLS 加密数据包，经 HTTP 进行通信。其设计主要目的是，提供对网站服务器的身份认证、保护交换数据的隐私与完整性。

HTTPS安全是由一套安全机制来保证的，主要包含这4个特性：机密性、完整性、真实性和不可否认性。

• 机密性：指传输的数据是采用Session Key（会话密钥）加密的，在网络上是看不到明文的。
• 完整性：指为了避免网络中传输的数据被非法篡改，使用MAC算法来保证消息的完整性。
• 真实性：指通信的对方是可信的，利用了PKI（Public Key Infrastructure 即『公钥基础设施』）来保证公钥的真实性。
• 不可否认性：无法伪装和否认，使用了签名的技术来保证的。

2. SSL/TLS

• SSL（Secure Socket Layer） 1994年由 浏览器开发商Netscape（网景通信公司） 率先倡导研发，为数据通讯提供安全支持，开发了最初的几个版本SSL 1.0、SSL 2.0、SSL 3.0。
• TLS（Transport Layer Security）前身为SSL，1999年从 3.1 开始被 IETF（Internet Engineering Task Force，Internet）标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2、TLS 1.3 四个版本。

目前互联网上被广泛使用的是TLS 1.1、TLS 1.2、TLS 1.3，TLS 协议的版本号v1.0 表示为0x0301，v1.1表示为0x0302，以此类推。值得一提的是，在TLS 1.3 中 client version 字段仍旧是 0x0303（v1.2 的一致），而是使用了supported_versions这个扩展来标识对于TLS v1.3的支持。

国密 SSL 规范主要是基于TLS v1.1版本，部分内容基于 TLS v1.2 版本，即是TLS 1.1和TLS 1.2的混合体，为了避免冲突选择了版本号 0x0101。这在实现上带来一定的麻烦，现有很多网络库会认为这是一个无效的协议版本，需要一一将判断修改过来。

3. 国密SSL握手

清楚了国密SSL 的协议后，我们就可以完整的看一下国密 SSL/TLS 的握手过程了，国密SSL/TLS 握手的过程大致可分为以下几个步骤：

1. Client Hello
   Client——>Server 客户端向服务端发送 Client Hello 消息。
2. Server Hello
   Server——>Client 服务端向客户端发送 Server Hello 消息。
3. Certificate
   Server——>Client 服务端下发 公钥证书。
4. Server Key Exchange
   Server——>Client 服务端下发秘钥交换的额外数据。
5. Server Hello Done
   Server——>Client 服务端握手信息发送完毕。
6. 证书合法性校验
   Client 对 Server下发的公钥证书进行合法性校验。
7. 协商加密秘钥
   Client——>Server 协商计算客户端、服务端通信的 加密秘钥enc_key，包括Client Key EXchange、Change Cipher Spec Protocol、Encrypted Handshake Message 三块流程。
8. Change Cipher Spec Protocol
   Server——>Client 服务端告知客户端后续的通信都采用协商的 秘钥enc_key 与 （商定的）算法 进行加密通信。
9. Encrypted Handshake Message
   Server——>Client 服务端用 秘钥enc_key 加密，发出的第一条加密消息。
10. Application Data
    Client——>Server SSL/TLS 握手完成，所有后续通信均采用 秘钥enc_key 加密。

国密SSL/TLS 完整握手流程如下图所示：

4. 国密 Wireshark 抓包

普通的wireshark 抓TCP/IP 包只能抓标准TLS 协议的，国密SSL/TLS 的版本号为 0x0101，默认会认为这是无效版本号，好在已经有支持国密版本的wireshark 版了，下面从抓包结果一步步查看国密SSL/TLS 的请求过程。

4.1. Client Hello

Client Hello（ Client——>Server ）： 客户端向服务端发送 Client Hello 消息。
消息中包含客户端的 TSL版本信息、秘钥随机数、加密套件候选列表、压缩算法候选列表、扩展字段等信息，相关信息抓包如下：

各字段详细描述如下：

• Version : TSL协议版本；
• Random：随机数 random_C 用于后续的密钥协商;
• Session ID：有或者无，有则客户端传上一次session的id可以恢复session；
• Cipher Suite：客户端支持的密码算法列表，供服务器选择；
• Compression Methods：客户端支持的压缩算法列表，用于后续的信息压缩传输；
• extensions：扩展字段；

4.2. Server Hello

Server Hello（ Server——>Client ）： 服务端向客户端发送 Server Hello 消息。
消息中包括服务端选择使用的TSL协议版本、选择的加密套件、选择的压缩算法、服务端生成的随机数等，相关信息抓包如下：

• Version：服务器选择的版本；
• Random：随机数random_S用于后续的密钥协商;
• Session ID：有或者无，有则客户端传上一次session的id可以恢复session；
• Cipher Suite：服务端选择的密钥算法；
• Compression Methods：服务端选择的压缩算法；

4.3. Certificate

Certificate（ Server——>Client ）：服务端下发 公钥证书 给客户端。相关信息抓包如下：

• Certificate: 服务端的公钥证书；

4.4. Server Key EXchange

Server Key Exchange（ Server——>Client ）:该消息的目的是 携带 密钥交换 的 额外数据。

该消息在协商的不同的算法套件会存在差异：

• 对于使用DHE/ECDHE非对称密钥协商算法的SSL握手，服务器发送其使用的DH（DH密钥交换）参数；
• 国密算法采用的是ECDHE（在RSA 算法、DH、ECDH不会发送server key exchange，DH、ECDH 是非前向安全性，已逐步废弃）。

4.5. Server Hello Done

Server Hello Done（ Server——>Client ）:
通知 Client，Server端已经将所有握手消息发送完毕。

4.6. 证书校验

客户端拿到 服务端 的公钥证书 后，需对该证书的合法性进行校验。校验内容如下：

• 证书链的可信性；
• 证书是否吊销；
• 证书有效期；
• 证书域名校验，核查证书域名是否与当前的访问域名匹配;

4.7. 协商通信秘钥

Client——>Server：这里包含三步，主要是协商计算客户端、服务端通信的加密秘钥。

Client Key Exchange：

Change Cipher Spec：

Encrypted Handshake Message：

• Client Key Exchange
  证书合法性验证通过之后，客户端产生随机数字 Pre-master。
  计算生成秘钥 enc_key {Fuc(random_C, random_S, Pre-Master) } 。
  将 Pre-master 与 enc_key 用 证书公钥加密（非对称算法）发送给服务端;
• Change Cipher Spec Protocol
  客户端 通知 服务端 后续的通信都采用协商的 秘钥enc_key 和商定好的 加密算法 进行加密通信;
• Encrypted Handshake Message
  客户端：客户端将之前 所有的握手数据（包括接受、发送）生成摘要；然后用 秘钥enc_key 加密（对称算法），发送给对应的服务端。
  服务端：服务端收到消息后，会用 秘钥enc_key 解密 客户端的摘要信息；然后用与客户端相同的算法生成 服务端摘要信息，最后对比两个摘要信息相同，则验证通过。

4.8.  服务端告知客户端并发送加密消息

Server——>Client：这里包含两步：

Change Cipher Spec Protocol:

服务器同样发送 Change Cipher Spec Protocol 告知客户端后续的通信都采用协商的 秘钥enc_key 与 算法 进行加密通信;

Encrypted Handshake Message：
服务端：服务端会将握手过程的消息生成摘要再用 秘钥enc_key 加密，这是服务端发出的第一条加密消息;
客户端：客户端接收后会用 秘钥enc_key 解密，能解出来说明协商的秘钥是一致的。

4.9. Application Data

Application Data Client——>Server ）：双方已安全地协商出了同一份 秘钥enc_key，所有的应用层数据都会用这个秘钥加密后再通过 TCP 进行可靠传输。

三 国密证书校验

1. 数字证书

1.1. 证书规范

数字证书简单的理解就是被信任的认证机构颁发且符合制定规范的数字签名证书，目前使用最广泛的证书是标准为ITU和ISO联合制定的X.509的 v3版本规范 (RFC5280）， 其中定义了如下证书信息：

X.509数字证书：

Certificate

Version Number （版本号）

Serial Number （序列号）

Signature Algorithm ID （证书签名算法ID）

Issuer Name （证书颁发者）

Validity period （证书有效时间）

Subject name （证书主体名称）

Subject Public Key Info （证书主体公钥信息）

Public Key Algorithm （证书公钥算法）

Subject Public Key （证书公钥）

Issuer Unique Identifier (optional) （发行商唯一ID）

Subject Unique Identifier (optional) （主体唯一ID）

Extensions (optional) （扩展）

Certificate Signature Algorithm （证书签名算法）

Certificate Signature （证书签名值）

1.2. 国密证书

目前国密证书也是采用的x509 规范格式，证书后缀一般用pem 或者cer。

编码格式分为:

• X.509 DER(Distinguished Encoding Rules)编码，后缀为：.der .cer .crt
• X.509 BASE64编码(PEM格式)，后缀为：.pem .cer .crt

DER 二进制格式的 Base64 编码，并在编码头尾加上起始行 -----BEGIN CERTIFICATE-----和结束行-----END CERTIFICATE-----

可以使用openssl 工具命令：openssl x509 -in ca.pem -inform pem -noout -text，将证书内容解析出来，下面是某一国密CA 证书的解析内容示例：

Certificate:

   Data:

       Version: 3 (0x2)

       Serial Number:

           32:7d:61:de:92:84:90:e2:f2:ea:c3:2a:67:ec:3d:d2:ef:54:6d:b1

   Signature Algorithm: 1.2.156.10197.1.501

       Issuer: C=CN, O=\xE5\x8C\x97\xE4\xBA\xAC\xE5\xA4\xA9\xE5\xA8\x81\xE8\xAF\x9A\xE4\xBF\xA1\xE7\x94\xB5\xE5\xAD\x90\xE5\x95\x86\xE5\x8A\xA1\xE6\x9C\x8D\xE5\x8A\xA1\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8, CN=vTrus SM2 Root CA G1

       Validity

           Not Before: Sep 15 09:13:37 2020 GMT

           Not After : Sep 15 09:13:37 2040 GMT

       Subject: C=CN, O=\xE5\x8C\x97\xE4\xBA\xAC\xE5\xA4\xA9\xE5\xA8\x81\xE8\xAF\x9A\xE4\xBF\xA1\xE7\x94\xB5\xE5\xAD\x90\xE5\x95\x86\xE5\x8A\xA1\xE6\x9C\x8D\xE5\x8A\xA1\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8, CN=vTrus SM2 OV SSL CA

       Subject Public Key Info:

           Public Key Algorithm: id-ecPublicKey

           Public-Key: (256 bit)

               pub:

                   04:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5:

                   af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e:

                   ed:b2:ac:2a:1b:4a:ec:80:7b:e7:1a:51:e0:df:f7:

                   c7:4a:20:7b:91:4b:20:07:21:ce:cf:68:65:8c:c6:

                   9d:3b:ef:d5:c1

               ASN1 OID: prime256v1

               NIST CURVE: P-256

       X509v3 extensions:

           X509v3 Subject Key Identifier:

               E2:8E:F7:A1:B3:95:65:83:52:D6:C1:37:19:C1:DE:71:17:05:A4:AA

           X509v3 Authority Key Identifier:

               keyid:E2:A5:14:62:46:BD:C6:E4:7D:FF:FD:E6:1B:F5:4E:B7:7E:31:45:7D

           X509v3 Basic Constraints: critical

               CA:TRUE, pathlen:0

           X509v3 Key Usage: critical

               Certificate Sign, CRL Sign

           X509v3 Extended Key Usage:

               TLS Web Server Authentication, TLS Web Client Authentication

           Authority Information Access:

               OCSP - URI:http://vtocsp-CDN.itrus.com.cn/ocsp/ocsp/ocsp

               CA Issuers - URI:http://vtca-cafiles.itrus.com.cn/ca/vTrusSM2RootCAG1.cer

           X509v3 CRL Distribution Points:

               Full Name:

                 URI:http://vtca-cafiles.itrus.com.cn/crl/vTrusSM2RootCAG1.crl

           X509v3 Certificate Policies:

               Policy: X509v3 Any Policy

                 CPS: https://www.itrus.com.cn/repository

   Signature Algorithm: 1.2.156.10197.1.501

        30:45:02:20:41:11:a8:06:e0:78:b0:0c:fd:06:22:cd:0b:cf:

        68:38:85:bb:3c:04:6d:27:6e:80:72:8e:3a:e8:e3:32:a6:4d:

        02:21:00:b4:81:62:9c:3f:af:12:46:d2:8e:a2:90:e0:5a:0b:

        7b:7f:28:96:8d:d6:7c:4f:8a:12:59:3e:3e:3c:35:ae:84

2. 国密证书校验

客户端（预置有CA 国密证书）验证服务端下发的证书，主要包括以下几个方面：

1. 校验证书是否是 受信任 的 CA根证书 颁发机构颁发；
2. 校验证书是否在上级证书的 吊销列表；
3. 校验证书 是否过期；
4. 校验证书 域名 是否 一致。

2.1. 证书可信性

校验国密证书是否可信：
校验国密证书是否是由受信任的CA根证书颁发机构颁发（目前只要是CFCA）。

为了确保 客户端 获取到的 服务端公钥 不被篡改，需要权威的 CA 机构。
CA机构负责 核实 公钥 拥有者 信息、颁发证书 (对服务端公钥进行签名)、同时为使用者 提供证书验证 服务。

• 服务方S 向第三方机构CA 提交公钥、组织信息、个人信息(域名)等信息并申请认证;（不交私钥）
• CA 通过线上、线下等多种手段 验证 申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等；
• 如信息审核通过，CA 会向申请者签发认证文件（证书）。

• 证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；
• 签名算法：首先使用散列函数计算公开的明文信息的信息摘要，然后使用 CA的私钥 对信息摘要进行加密，密文即签名；

• 客户端 C 向服务器 S 发出请求时，服务器 S 返回证书；
• 客户端 C 读取证书中的相关的明文信息，采用相同的散列函数 计算得到 信息摘要，然后用本地信任的 CA证书公钥 解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法；
• 客户端 然后验证证书相关的域名信息、有效时间等信息;

证书 = 公钥（服务方生成密码对中的公钥）+ 申请者与颁发者信息 + 签名（用CA机构生成的密码对的私钥进行签名）;

2.2. 证书吊销

CA机构 能够 签发证书，同样也存在机制 宣布 以往签发的 证书无效。若证书的申请主体出现：私钥丢失、申请证书无效等情况，CA机构需要废弃该证书。

证书是有生命周期的，如果私钥泄漏了那这个证书就得吊销，主要存在两类吊销方式：CRL 与 OCSP。

• CRL（Certificate Revocation List）
  证书吊销列表：是一个单独的文件，该文件包含了 CA机构 已经吊销的证书序列号与吊销日期；
  证书中一般会包含一个 URL 地址 CRL Distribution Point，通知使用者去哪里下载对应的 CRL 以校验证书是否吊销。
  该吊销方式的优点是不需要频繁更新，但是不能及时吊销证书，因为 CRL 更新时间一般是几天，这期间可能已经造成了极大损失。
• OCSP（Online Certificate Status Protocol）
  证书状态在线查询协议：一个实时查询证书是否吊销的方式。
  请求者发送证书的信息并请求查询，服务器返回正常、吊销或未知中的任何一个状态。
  证书中一般也会包含一个 OCSP 的 URL 地址，但这就要求查询服务器需要具有良好的性能。

2.3. 证书过期

校验证书的有效期是否已经过期：主要判断证书中 Validity period 字段是否过期。

3. 国密证书链

在 CA 根证书和服务器证书中间增加一级证书机构，即中间证书，证书的产生和验证原理不变，只是增加一层验证，只要最后能够被任何信任的 CA根证书 验证合法即可。

服务器证书、中间证书与根证书在一起组合成一条合法的证书链，证书链的验证是自下而上的信任传递的过程。

中间证书结构存在的优势：

• 减少根证书结构的管理工作量，可以更高效的进行证书的审核与签发;
• 根证书一般预置在客户端 中，私钥一般离线存储，一旦私钥泄露，则吊销过程非常困难，无法及时补救;
• 中间证书结构的私钥泄露，则可以快速在线吊销，并重新为用户签发新的证书;
• 证书链四级以内一般不会对 HTTPS 的性能造成明显影响。

3.1. 证书链特点

• 同一本服务器证书可能存在多条合法的证书链。
     因为证书的生成和验证基础是公钥和私钥对，如果采用相同的公钥和私钥生成不同的中间证书，针对被签发者而言，该签发机构都是合法的 CA，不同的是中间证书的签发机构不同;
• 不同证书链的层级不一定相同，可能二级、三级或四级证书链。
     中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构，所以证书链层级不一定相同。

3.2. 证书链校验

• 客户端 通过 服务器证书 中 签发机构信息，获取到 中间证书公钥；利用 中间证书公钥 进行 服务器证书 的签名验证。

• 中间证书公钥解密 服务器签名，得到证书摘要信息；
• 摘要算法计算 服务器证书 摘要信息；
• 对比两个摘要信息。

• 客户端 通过 中间证书 中 签发机构信息，客户端本地查找到 根证书公钥；利用 根证书公钥 进行 中间证书 的签名验证。

四 小结

通过上面章节描述，我们已经清楚的了解了国密HTTPS 和国密SSL 链路的完整机制。目前市场上已有的国密厂商种类繁多，有纯提供硬件的厂商、软件国密资质的厂商、和提供后端硬件及对应软件接入的厂商。

为了能解决客户国密SSL 改造的需求，我们也对市场主流的国密厂商的实现机制、方案等做了考察和研究，后面会整理一篇对应的国密改造实践文档也一并分享，谢谢。