接上篇 理解加密算法(一)——加密算法分类

SSL与TLS的关系

1994年,Mozilla 前身 NetScape 公司制定出 1.0 版本。

1995年,NetScape 正式发布 SSL,版本是 2.0。

1996年,NetScape 发布 3.0,获得广泛应用。

1999年,ISOC 接管 SSL,制定世界标准同时升级 SSL 版本,改称 TLS,版本 1.0。

2001年,ISOC 的较新版本 TLS 1.2。

注:TLS 1.0 等同于 SSL 3.1,TLS 1.1 等同于 SSL 3.2,TLS 1.2 等同于 SSL 3.3。

即:TLS是SSL的进化版。

SSL/TLS的作用

不使用SSL/TLS的HTTP通信,就是不加密的通信。所有信息明文传播,带来了三大风险。

  • 窃听风险(eavesdropping):第三方可以获知通信内容。
  • 篡改风险(tampering):第三方可以修改通信内容。
  • 冒充风险(pretending):第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的,希望达到:

  • 所有信息都是加密传播,第三方无法窃听。
  • 具有校验机制,一旦被篡改,通信双方会立刻发现。
  • 配备身份证书,防止身份被冒充。

理解加密算法(一)——加密算法分类中有对非对称加密进行介绍,理论上要达到上面的效果,由服务端生成一对公钥和私钥,由CA机构制作包含公钥的CA证书后颁发给客户端,客户端用公钥加密数据之后再发送给服务端,但是这样依然有两个问题:

  • 非对称加密算法性能较低,大大降低数据传输效率
  • 由于证书是公开的,服务端用私钥加密数据发给客户端依然是不安全的

为了解决这两个问题,TLS采取了使用组合加密技术的办法,其工作流程分为三个基本阶段:

  • ①对等协商支援的密钥算法
  • ②基于私钥加密交换公钥、基于PKI证书的身份认证
  • ③基于公钥加密的数据传输保密

TLS协议包括两个协议组―― TLS 记录协议和 TLS 握手协议,其中握手协议阶段确定双方要使用的加密算法类型,以及会话的对称加密秘钥,对应着上面的第②个阶段;记录协议阶段通过握手协议得到的对称加密秘钥,要加密通信内容,对应着上面第③个阶段。

TLS 握手协议

下面是TLS握手协议的流程图:

得到Session Key之前的通信,除了客户端生成的第三个随机值Random Parameter Secret之外, 都是不安全的。客户端和服务端根据client random、server random、random parameter secret三个随机值,通过约定的算法来得到相同的一个对称加密秘钥Seesion Key,由于第三个随机值的传输是安全的,所以可以保证Seesion Key也是安全的。
通信双方通过握手建立了对话连接之后,整个过程只需要使用这一个session key,而不需要每次发送信息都生成。
可见:

  • 整个握手过程只使用了一次非对称加密,后续的传输过程也可以不使用非对称加密,传输效率高
  • 两边的数据收发都会使用对称加密,数据传输安全。其中由三个随机数生成对称加密秘钥的方案,由上节所说第①阶段,对等协商支援的密钥算法,来约定。

TLS 记录协议

TLS 记录协议提供的连接安全性具有两个基本特性:

  • 私有――对称加密用以数据加密
  • 可靠――传输内容里边包含秘钥相关散列函数(MAC或HMAC等)计算得到的散列值,收到数据后可依此校验数据完整性。

TLS会话恢复

TLS建立安全连接的过程是非常耗时的,当连接因为某些原因断开,需要重连时,频繁建立连接会降低数据传输效率,所以TLS有一些机制来保存会话的加密方式信息和秘钥。

Seesion ID

这种方式是会话建立之后客户端服务端各自保存一份加密方法和秘钥信息,使用相同的会话ID来标识,重连的时候若找到了匹配的会话ID,则直接使用之前的加密方式和秘钥,不需要重新走秘钥生成的过程。

Seesion Ticket

上面session id的方式在浏览器中支持比较广泛,但是对于服务端来说,如果服务端存在多机部署的情况,重连的时候可能会重连到另外一台机器上,这样会话就恢复不了了需要重新连接。还有一种策略是服务端将会话的加密方式和秘钥加个密,然后将密文存储在客户端,重连的时候客户端将密文发送给服务端,服务端若可以解密得到加密方式和秘钥,则不需要重新走秘钥生成的过程。

☞ 参与评论