ssl/tsl

有了前面加密和哈希以及数字证书和数字签名两篇文章的铺垫，终于可以来认识HTTPS的核心所在了，SSL/TLS协议。本篇从SSL/TLS发展历史到握手以及传输的详细过程来讲解。
此篇文章的逻辑图

图0-0 此篇文章的逻辑图

SSL/TLS协议概览

SSL/TLS协议是什么

计算机网络的OSI七层模型和TCP/IP四层模型想必大家都知道。其中SSL/TLS是一种介与于传输层（比如TCP/IP）和应用层（比如HTTP）的协议。它通过"握手协议(Handshake Protocol)"和"传输协议(Record Protocol)"来解决传输安全的问题。SSL/TLS是一个可选层，没有它，使用HTTP也可以通信，它存在的目的就是为了解决安全问题，这也就是HTTPS相对于HTTP的精髓所在。

SSL/TLS协议发展历史

SSL/TLS协议发展历史参看下表，更详细的发展历史参看维基百科的SSL/TLS协议发展历史。

Protocol	Year	RFC	Description
SSL 1.0	1994		NetScape公司设计1.0版 但是未发布
SSL 2.0	1995.02		NetScape公司发布SSL 2.0版
SSL 3.0	1996	RFC 6101	NetScape公司发布SSL 3.0版
TLS 1.0	1999	RFC 2246	IETF将SSL标准化 改名为TLS 发布1.0版
TLS 1.1	2006.04	RFC 4346	发布TLS1.1版
TLS 1.2	2008.08	RFC 5246	发布TLS1.2版
TLS 1.3			TLS 1.3还是一个互联网草案 待发布

目前，应用最广泛的是TLS 1.0，接下来是SSL 3.0。但是，主流浏览器都已经实现了TLS 1.2的支持。值得一提的是iOS9的App，需将HTTP连接升级到HTTPS，并且TLS版本不得低于1.2(当然升级为HTTPS并非必须的)。

SSL/TLS运行过程

SSL/TLS运行过程概述

上面提到SSL/TLS有两个阶段握手协议和传输协议，握手协议就是建立起连接的过程，这个阶段采用非对称加密，这个过程完毕后会生成一个对话秘钥，从而传输协议过程，就是用这个对话秘钥使用对称加密进行传输。之所以这样做，是因为，非对称加密是很耗性能的。而握手协议过程中，使用数字证书保证了公钥的安全性。当然这个过程既可以双向证书验证，也可以只验证服务端的证书单向证书验证。这也是前两节所作的铺垫，不至于这儿看的太迷糊。

SSL/TLS运行过程详解

图2-0 SSL/TLS运行过程详解

结合上图(图2-0)，我来说明上图中一步步的都发生了什么？

客户端发出请求(Client Hello)

对应上图第一步，客户端发出请求，这一步客户端主要向服务端提供以下信息：

• 支持的SSL/TLS协议版本
• 支持的加密套件列表(cipher suite)
• 支持的压缩算法列表(compression methods)，用于后续的压缩传输
• 产生的一个随机数random_C(random number)，客户端有存留，稍后用于生成"对话密钥(session key)"

服务端回应(Server Hello)

收到客服端的请求之后，服务端向客户端回应以下信息：

• 根据客户端支持的SSL/TLS协议版本，和自己的比较确定使用的SSL/TLS协议版本，如果没有合适的，对话关闭
• 回应加密套件，压缩算法
• 产生的一个随机数random_S(random number)，服务端有存留，稍后用于生成"对话密钥(session key)"
• 服务端数字证书(证明自己的身份，传递公钥)
• 如果需要验证客户端，发出请求，要求客户端提供证书

客户端回应

客户端收到服务端的回应后，首先验证服务端的数字证书，如果证书没有问题继续下去，如果证书有问题，则会有相应提示，或者对话直接关闭。然后客户端在向服务端发送以下信息：

• 如果服务端有请求证书，发送自己的数字证书
• 在产生一个随机数pre-master key(random number)，并且用服务端数字证书中的公钥加密
• 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送

服务端最后的回应

如果有客户端的证书，就先验证客户端的证书

• 使用自己的私钥，对随机数pre-master key解密，这时客户端和服务端各自有了三个随机数，然后用原来协商的加密方式生成本次通话使用的会话密钥(session key)
• 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送

这时客户端和服务端都有了session key，然后握手协议阶段就结束了。下面开始使用session key对称加密数据，进行传输，就进入了下一个阶段，传输协议过程。

总结

这块的重点在与SSL/TSL协议的握手协议过程。在第三步，客户端验证证书的时候，如果服务端的证书在系统默认信任证书列表中(系统会默认信任一些CA认证中心的根证书)则会直接通过，如果没有在系统默认信任证书列表中，浏览器可能会弹窗让用户选择是否信任该证书，也有可能会直接关闭连接，提示用户，证书不可信。而在App内，如果想要信任未在系统信任列表中的证书，则需要在App内提前置入服务端证书，关于这一点有讲。而关于认证方式，大多数也都是采用的单向认证，也就是说仅仅认证服务端的证书，而像银行等机构则多使用双向认证的方式。

作者：TIME_for
链接：https://www.jianshu.com/p/c93612b3abac
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。