SSL/TLS

一: 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: IETF正在酝酿中

下面我们将介绍 TLS1.x 如何保证通讯安全。

---

二: CA & SSL Server & SSL Client 介绍

如何保证安全呢？你说安全就安全吗，究竟是怎么实现的呢？绝对安全吗？
哈，有人的地方就有江湖，有江湖的地方就没有绝对的安全。但 SSL/TLS 确实可以极大程度保证信息安全。下面根据图一 SSL/TLS 工作流来一览实现过程。

2.1 SSL/TLS 工作流

图一 SSL/TLS 工作流

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

1. CA本身是受信任的 // 国际认可的
2. 给他受信任的申请对象颁发证书 // 和办理护照一样，要确定你的合法身份，你不能是犯罪分子或造反派。当然，你需要被收保护费，同时，CA可以随时吊销你的证书。
   证书长啥样？其实你的电脑中有一堆CA证书。你可以看一看：
   360浏览器: 选项/设置-> 高级设置 -> 隐私于安全 -> 管理 HTTPS/SSL 证书 -> 证书颁发机构
   火狐浏览器: 首选项 -> 高级 -> 证书 -> 查看证书 -> 证书机构
   chrome浏览器: 设置 -> 高级 -> 管理证书 -> 授权中心
   ubuntu: /etc/ssl/certs
   这些都是 CA 的证书！

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

2.2 单向认证双向认证

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

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

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

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）数据传输：Server和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，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析;

(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).加密通信

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