SSL/TLS 双向认证(一) — SSL/TLS 工作原理

大家好，又见面了，我是你们的朋友全栈君。

本文部分参考：
https://www.wosign.com/faq/faq2016-0309-03.htm
https://www.wosign.com/faq/faq2016-0309-04.htm
http://blog.csdn.net/hherima/article/details/52469674

一: SSL/TLS 介绍

什么是 SSL, 什么是 TLS 呢？官话说 SSL 是安全套接层 (secure sockets layer), TLS 是 SSL 的继任者，叫传输层安全 (transport layer security)。说白点，就是在明文的上层和 TCP 层之间加上一层加密，这样就保证上层信息传输的安全。如HTTP 协议是明文传输，加上 SSL 层之后，就有了雅称 HTTPS。它存在的唯一目的就是保证上层通讯安全的一套机制。它的发展依次经历了下面几个时期，像手机软件升级一样，每次更新都添加或去除功能，比如引进新的加密算法，修改握手方式等。

SSL1.0: 已废除
SSL2.0: RFC6176, 已废除
SSL3.0: RFC6101, 基本废除
TLS1.0: RFC2246, 少数古董服务器仍在使用
TLS1.1: RFC4346
TLS1.2: RFC5246, 目前已广泛使用
TLS1.3: RFC8446
下面我们将介绍 TLS1.x 如何保证通讯安全。

---

二: CA & SSL server & SSL client 介绍

如何保证安全呢？你说安全就安全吗，究竟是怎么实现的呢？绝对安全吗？

哈，有人的地方就有江湖，有江湖的地方就没有绝对的安全。但 SSL/TLS 确实可以极大程度保证信息安全。
下面根据图一 SSL/TLS 工作流来一览实现过程。

2.1 SSL/TLS 工作流

图一 SSL/TLS 工作流

Q1: CA 介绍

CA: 证书授权中心 (certificate authority)
它呢，类似于国家出入境管理处一样，给别人颁发护照；
也类似于国家工商管理局一样，给公司/企业颁发营业执照。

CA 有两大主要性质：

• CA 本身是受信任的（国际认可的）
• 给他受信任的申请对象颁发证书

和办理护照一样，要确定你的合法身份，你不能是犯罪分子或造反派。当然，你需要被收保护费，同时，CA 机构可以随时吊销你的证书。

Q2: CA 证书长啥样

其实你的电脑中有一堆证书。你可以看一看嘛：

• 360 浏览器: 选项/设置-> 高级设置 -> 隐私于安全 -> 管理 HTTPS/SSL 证书 -> 证书颁发机构
• 火狐浏览器: 首选项 -> 高级 -> 证书 -> 查看证书 -> 证书机构
• chrome浏览器: 设置 -> 高级 -> 管理证书 -> 授权中心
• ubuntu: /etc/ssl/certs/xxx_CA.pem (或 xxx_Certification_Authority.pem)

这些都是 CA 的证书！

Q3: CA 的证书 ca.crt 和 SSL server 的证书 server.crt 是什么关系呢

1. SSL server 自己生成一个私钥/公钥对。server.key/server.pub // 私钥加密，公钥解密！
2. server.pub 生成一个请求文件 server.req. 请求文件中包含有 server 的一些信息，如域名/申请者/公钥等
3. server 将请求文件 server.req 递交给 CA 机构，CA 机构验明正身后，将用 ca.key 和请求文件加密生成 server.crt
4. 由于 ca.key 和 ca.crt 是一对，于是 ca.crt 可以用来校验 server.crt

说明：为了简化 CA 校验证书的过程，本文只介绍了最基本的情况。在实际大多数情况下：

1. server 端的证书颁发机构 CA 和 client 端的证书颁发机构 CA 通常不同
2. 证书实际情况下，可以是证书链，也就是多个上级机构逐级下发证书的链
3. 证书校验时，CA 通常可以选择校验证书链的深度，最基础的情况是只校验一级

Q4: 举例说明

如果 SSL client 想要校验 SSL server. 那么 SSL server 必须要将他的证书 server.crt 传给 client. 然后 client 用 ca.crt 去校验 server.crt 的合法性。
如果 server 是一个钓鱼网站，那么 CA 机构是不会给他颁发合法 server.crt 证书的，这样 client 用 ca.crt 去校验，就会失败。
比如：浏览器作为一个 SSL client, 你想访问合法的淘宝网站 https://www.taobao.com, 结果不慎访问到 https://wwww.jiataobao.com, 那么浏览器将会检验到这个假淘宝钓鱼网站的非法性，提醒用户不要继续访问！这样就可以保证 client 的所有 https 访问都是经过安全检查的。

2.2 不认证 & 单向认证 & 双向认证

何为 SSL/TLS 单向认证，双向认证？

单向认证：指的是只有一个对象校验对端的证书合法性
通常是客户端来校验服务器的合法性。那么 client 需要一个 ca.crt, 服务器需要 server.crt, server.key

例如：浏览器校验各个 HTTPS 网站的合法性。如果导航栏有绿色的小锁，说明网站合法；如果是红色小锁，说明该网站证书校验不过。

也可以是服务器来校验客户端的合法性。那么 server 需要一个 ca.crt, 客户端需要 client.crt, client.key

例如: 亚马逊物联网平台(AWS IoT) 给每个设备颁发证书，所有设备要想连接上 AWS, 必须使用其提供的客户端证书

双向认证：指的是相互校验，服务器需要校验每个 client 证书, client 也需要校验服务器证书
server 需要 server.key 、server.crt 、ca.crt
client 需要 client.key 、client.crt 、ca.crt

不认证：指的是不相互校验证书，但仍然使用 TLS 连接

证书校验只是 TLS 连接过程中的一小步，是可以省略的过程

2.3 证书详细工作流

图二 证书详细工作流

1）申请认证：服务器需自己生成公钥私钥对 pub_svr & pri_svr，同时根据 pub_svr 生成请求文件 csr, 提交给 CA 机构，csr 中含有公钥、组织信息、个人信息（域名）等信息。(图一中 server.req 就是 csr 请求文件)

2）审核信息：CA 机构通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等。

3）签发证书：如信息审核通过，CA 机构会向申请者签发认证文件：证书。
证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。
签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名。（图一中生成 server.crt）

4）返回证书：client 如果请求验证服务器，服务器需返回证书文件。（图一中 handshake 传回 server.crt）

5）client验证证书：client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法。客户端然后验证证书相关的域名信息、有效时间是否吊销等信息。
客户端会内置信任 CA 的证书信息（包含公钥），如果 CA 不被信任，则找不到对应 CA 的证书，证书也会被判定非法。(图一中 check 可选，我们可以选择不验证服务器证书的有效性)

6）秘钥协商：验证通过后，server 和 client 将进行秘钥协商。接下来 server 和 client 会采用对称秘钥加密。(对称加密时间性能优)（图一中 pre-master/change_cipher_spec/encrypted_handshake_message 过程）

7）数据传输：SSL server 和 SSL client 采用对称秘钥加密解密数据。

2.4 SSL/TLS单向认证流程

(1) client_hello

客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下：

• 支持的最高 TLS 协议版本 version，从低到高依次 SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2, 当前基本不再使用低于 TLSv1 的版本
• 客户端支持的加密套件 cipher suites 列表， 每个加密套件对应前面 TLS 原理中的四个功能的组合：
  • 认证算法 Au (身份验证)
  • 密钥交换算法 KeyExchange (密钥协商)
  • 对称加密算法 Enc (信息加密)
  • 信息摘要 Mac (完整性校验)
• 支持的压缩算法 compression methods 列表，用于后续的信息压缩传输
• 随机数 random_C，用于后续的密钥的生成
• 扩展字段 extensions，支持协议与算法的相关参数以及其它辅助信息等，常见的 SNI 就属于扩展字段，后续单独讨论该字段作用

(2) server_hello + server_certificate + sever_hello_done

• server_hello, 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 等，其中随机数用于后续的密钥协商
• server_certificates, 服务器端配置对应的证书链，用于身份验证与密钥交换
• server_hello_done，通知客户端 server_hello 信息发送结束

(3) 证书校验

• 证书/证书链的可信性 trusted certificate path，方法如前文所述
• 证书是否吊销 revocation，有两类方式离线 CRL 与在线 OCSP，不同客户端行为会不同
• 有效期 expiry date，证书是否在有效时间范围
• 域名 domain，核查证书域名是否与当前的访问域名匹配 (CN 字段)

证书校验没有强制的过程，也就是校验严格和校验宽松通常都是可以配置的，由校验端来确定。

(4) client_key_exchange + change_cipher_spec + encrypted_handshake_message

• client_key_exchange: 合法性验证通过之后，客户端计算产生随机数字 pre-master，并用证书公钥加密，发送给服务器
• 此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 pre-master，计算得到协商密钥
  enc_key=Fuc(random_C, random_S, pre-master)
• change_cipher_spec: 客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;
• encrypted_handshake_message: 结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证

(5) change_cipher_spec + encrypted_handshake_message

• 服务器用私钥解密加密的 pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, pre-master);
• 计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;
• change_cipher_spec, 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;
• encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端;

(6) 握手结束

客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成

(7) 加密通信

开始使用协商密钥与算法进行加密通信。

2.5 实际 wireshark 分析

我们搭建的 SSL/TLS 服务器是 192.168.111.100, client 是192.168.111.101. client 需要认证 server 的合法性。
我们只看 TLSv1.1 的数据包：
第一包 (No. 25) Client Hello 包，即 SSL/TLS 单向认证流程的 (1)
第二包 (No. 27) Server Hello 包，包含服务器证书等。即 SSL/TLS 单向认证流程的 (2)
第三包 (No. 28) 服务器证书验证完成，同时发送 client key exchange+change cipher spec + encrypted handshake message.即 SSL/TLS 单向认证流程的(4)
第四包 (No. 29) 秘钥协商，change cipher spec + encrypted hanshake message.即 SSL/TLS 单向认证流程的 (5)
第五包 (No. 30) 握手完成。开始上层数据传输。SSL/TLS 单向认证流程的 (7)

2.6 SSL/TLS 双向认证流程

和单向认证几乎一样，只是在 client 认证完服务器证书后，client 会将自己的证书 client.crt 传给服务器。服务器验证通过后，开始秘钥协商。

实际 wireshark 分析：

和单向认证一样:
我们搭建的 SSL/TLS 服务器是 192.168.111.100, client是192.168.111.101. client 需要认证 server 的合法性，server 也需要认证 client 的合法性

我们只看 TLSv1.1 的数据包：
第一包 (No. 55) Client Hello 包，即 SSL/TLS 单向认证流程的 (1)
第二包 (No. 57) Server Hello 包，包含服务器证书等。即 SSL/TLS 单向认证流程的 (2)
第三包 (No. 60) 服务器证书验证完成，同时发送客户端的证书 client.crt ,同时包含 client key exchange+change cipher spec + encrypted handshake message. 即 SSL/TLS 单向认证流程的 (4)
第四包 (No. 61)**服务器验证客户端证书的合法性。**通过后进行秘钥协商，change cipher spec + encrypted hanshake message.即 SSL/TLS 单向认证流程的 (5)
重传包 (No. 62) 由于网络原因，TCP 重传第No. 60 包。
第五包 (No. 64) 握手完成，开始上层数据传输。SSL/TLS 单向认证流程的 (7)

2.7 证书等格式说明

crt/key/req/csr/pem/der 等拓展名都是什么东东？

.crt 表示证书, .key 表示私钥, .req 表示请求文件,.csr 也表示请求文件, .pem 表示 pem 格式，.der 表示 der 格式。

文件拓展名你可以随便命名，只是为了理解需要而命名不同的拓展名。但文件中的信息是有格式的，和 exe，PE 格式一样。

证书有两种格式：pem 格式和 der 格式

所有证书，私钥等都可以是 pem, 也可以是 der 格式，取决于应用需要。
pem 和 der 格式可以互转:

openssl x509 -in ca.crt -outform DER -out ca.der  # pem -> der
openssl x509 -inform der -in ca.der -out ca.pem   # der -> pem

pem 格式：经过加密的文本文件，一般有下面几种开头结尾：

	-----BEGIN RSA PRIVATE KEY-----
	-----END RSA PRIVATE KEY-----
	or:
   -----BEGIN CERTIFICATE REQUEST-----
   -----END CERTIFICATE REQUEST-----
	or:
   ----BEGIN CERTIFICATE-----
  -----END CERTIFICATE-----

der 格式: 经过加密的二进制文件。

如何查看证书中有什么

证书中含有 申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。如查看百度证书详细信息。

a) 先下载百度证书
火狐浏览器访问 https://www.baidu.com/, 点击左上角绿色小锁，点击向右箭头，点击更多信息，点击查看证书，点击详细信息，点击导出。即可导出百度的证书 baiducom.crt

b) 命令查看证书详细信息

openssl x509 -noout -text -in baiducom.crt

详细信息中，有一个字段： X509v3 Basic Constraints: CA: FALSE
该字段指出该证书是否是 CA 证书，还是一般性的非 CA 证书。详细描述见 RFC5280#section-4.2.1.9，同时 RFC5280 也详细描述证书工作方式等。

2.8 SSL/TLS 和 OpenSSL, mbedTLS 是什么关系

SSL/TLS 是一种工作原理，OpenSSL 和 mbedTLS 是 SSL/TLS 的具体实现，很类似于 TCP/IP 协议和 socket 之间的关系。

三: 本地生成 SSL 相关文件

3.1 证书生成脚本

我们自己本地使用 makefile.sh 脚本建立一个CA (ca.crt + ca.key)，用这个 CA 给 server 和 client 分别颁发证书。

makefile.sh

# * Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# * Neither the name of the axTLS project nor the names of its
# contributors may be used to endorse or promote products derived
# from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
# TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY 
# OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
# NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
# THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
#
# Generate the certificates and keys for testing.
#
PROJECT_NAME="TLS Project"
# Generate the openssl configuration files.
cat > ca_cert.conf << EOF  
[ req ]
distinguished_name     = req_distinguished_name
prompt                 = no
[ req_distinguished_name ]
O                      = $PROJECT_NAME Dodgy Certificate Authority
EOF
cat > server_cert.conf << EOF  
[ req ]
distinguished_name     = req_distinguished_name
prompt                 = no
[ req_distinguished_name ]
O                      = $PROJECT_NAME
CN                     = 192.168.111.100
EOF
cat > client_cert.conf << EOF  
[ req ]
distinguished_name     = req_distinguished_name
prompt                 = no
[ req_distinguished_name ]
O                      = $PROJECT_NAME Device Certificate
CN                     = 192.168.111.101
EOF
mkdir ca
mkdir server
mkdir client
mkdir certDER
# private key generation
openssl genrsa -out ca.key 2048
openssl genrsa -out server.key 2048
openssl genrsa -out client.key 2048
# cert requests
openssl req -out ca.req -key ca.key -new \
-config ./ca_cert.conf
openssl req -out server.req -key server.key -new \
-config ./server_cert.conf 
openssl req -out client.req -key client.key -new \
-config ./client_cert.conf 
# generate the actual certs.
openssl x509 -req -in ca.req -out ca.crt \
-sha1 -days 5000 -signkey ca.key
openssl x509 -req -in server.req -out server.crt \
-sha1 -CAcreateserial -days 5000 \
-CA ca.crt -CAkey ca.key
openssl x509 -req -in client.req -out client.crt \
-sha1 -CAcreateserial -days 5000 \
-CA ca.crt -CAkey ca.key
openssl x509 -in ca.crt -outform DER -out ca.der
openssl x509 -in server.crt -outform DER -out server.der
openssl x509 -in client.crt -outform DER -out client.der
mv ca.crt ca.key ca/
mv server.crt server.key server/
mv client.crt client.key client/
mv ca.der server.der client.der certDER/
rm *.conf
rm *.req
rm *.srl 

将上述代码保存为 makefile.sh
做如下修改，终端执行。

– 修改 CN 域中 IP 地址为你主机/设备的 IP 地址
– [可选] 加密位数 2048 修改为你需要的加密位数

将会看到：

ca目录：保存 ca 的私钥 ca.key 和证书 ca.crt
certDER目录:将证书保存为二进制文件 ca.der, client.der, server.der
client目录: client.crt, client.key
server目录:server.crt, server.key

3.2 删除脚本

rmfile.sh

rm ca/ -rf
rm certDER/ -rf
rm client/ -rf
rm server/ -rf

将上述代码保存为 rmfile.sh, 终端执行，将会删除产生过的目录和文件：

./rmfile.sh

3.3 CA 校验证书测试

我们可在本地使用 CA 证书来分别校验由自己颁发的服务器证书 server.crt 和客户端证书 client.crt

$openssl verify -CAfile ca/ca.crt server/server.crt

$openssl verify -CAfile ca/ca.crt client/client.crt