SSL/TLS算法流程解析

 

SSL/TLS 早已不是陌生的词汇,然而其原理及细则却不是太容易记住。本文将试图通过一些简单图示呈现其流程原理,希望读者有所收获。

 

一、相关版本

Version Source Description   Browser Support
SSL v2.0 Vendor Standard

 (from Netscape Corp.) [SSL2]

First SSL protocol for which implementations exist - NS Navigator 1.x/2.x 
- MS IE 3.x 
- Lynx/2.8+OpenSSL
SSL v3.0

Expired Internet Draft

(from Netscape Corp.) [SSL3]

Revisions to prevent specific security attacks, add non-RSA ciphers and support for certificate chains - NS Navigator 2.x/3.x/4.x 
- MS IE 3.x/4.x 
- Lynx/2.8+OpenSSL
TLS v1.0

Proposed Internet Standard

(from IETF) [TLS1]

 Revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for block ciphers, message order standardization and more alert messages. -Lynx/2.8+OpenSSL 

 

SSL全称为 Socket Security Layer,TLS全称为Transport Layer Security,这两者没有本质的区别,都是做的传输层之上的加密(介于传输层及应用层之间)。TLS是后续SSL版本分支的名称,花费长时间去争论两者的优劣没有意义。目前TLS最新版本为 TLS1.2(也称为SSL3.3)

 

二、SSL/TLS 解决的问题

信息被窃听(wiretap),第三方随时随地获得通讯内容;

    SSL/TLS 实现了传输信息的加密。

数据被篡改(tampering),第三方可修改传输中的数据;

    SSL/TLS 实现了数据签名及校验。

身份被冒充(pretending),第三方可冒充通讯者身份传输数据;

    SSL/TLS 采用了CA数字证书认证机制。

 

三、握手阶段

简单点说,SSL/TLS对于传输层的加密是通过动态密钥对数据进行加密实现的,而动态密钥则通过握手流程协商制定;为了保证动态密钥的安全性,其中免不了使用公钥加密算法(非对称)、数字证书签名等技术手段。

一个SSL/TLS 握手过程需要协商的信息包括:

 1 协议的版本号;

 2 加密算法,包括非对称加密算法、动态密钥算法;

 3 数字证书,传输双方通过交换证书及签名校验对彼此进行鉴权;

 4 动态密钥,传输数据过程使用该密钥进行对称加解密,该密钥通过非对称密钥进行加密传输。

 

四、流程解析

一个典型的SSL/TLS 握手流程包括双向认证,如下所示:

 

1. 客户端发出一个 client hello 消息,携带的信息包括:

    所支持的SSL/TLS 版本列表;支持的与加密算法;所支持的数据压缩方法;随机数A;

2. 服务端响应一个 server hello 消息,携带的信息包括:

    协商采用的SSL/TLS 版本号;会话ID;随机数B;服务端数字证书 serverCA;

    由于双向认证需求,服务端需要对客户端进行认证,会同时发送一个 client certificate request,表示请求客户端的证书;

3. 客户端校验服务端的数字证书;校验通过之后发送随机数C,该随机数称为pre-master-key,使用数字证书中的公钥加密后发出;

    由于服务端发起了 client certificate request,客户端使用私钥加密一个随机数 clientRandom随客户端的证书 clientCA一并发出;

4. 服务端校验客户端的证书,并成功将客户端加密的随机数clientRandom 解密;

    根据 随机数A/随机数B/随机数C(pre-master-key) 产生动态密钥 master-key,加密一个finish 消息发至客户端;

5. 客户端根据 同样的随机数和算法 生成master-key,加密一个finish 消息发送至服务端;

6. 服务端和客户端分别解密成功,至此握手完成,之后的数据包均采用master-key进行加密传输。

 

五、要点解析

双向认证和单向认证

双向认证更好的解决了身份冒充问题,服务端提供证书的同时要求对客户端身份进行认证;然而在一些常见的应用场景下往往只有单向认证,如采用https网站只需要求客户端(浏览器)对服务端的证书进行认证。

在单向认证场景下,握手阶段2服务端不会发出 client certificate request,之后服务端也不需要校验客户端证书;

在双向认证场景下,客户端如果无法提供证书,会发出 no digital certificate alert 的警告信息,此时可能导致握手失败(根据服务端策略而定);

 

随机数的使用

由于数字证书是静态的,因此要求使用随机因素来保证协商密钥的随机性;对于RSA 算法来说,pre-master-key本身就是一个随机数,再加上hello消息中的随机,三个随机数通过一个密钥导出器最终导出一个对称密钥。

之所以采用 pre-master-key 机制是因为SSL协议不信任每个主机都能产生完全随机的随机数,如果 pre-master-key 不随机,那么被猜出来的风险就很大,于是仅仅使用 pre-master-secret作为密钥不合适,需要引入新的随机因素,也就是同时结合hello消息中的双向随机数。

 

会话密钥重用

SSL/TLS握手过程比较繁琐,同时非对称加解密性能比对称密钥要差得多;如果每次重建连接时都需要进行一次握手会产生较大开销,因此有必要实现会话的重用以提高性能。

常用的方式包括:

SessionID(RFC 5246),客户端和服务端同时维护一个会话ID和会话数据状态;重建连接时双方根据sessionID找到之前的会话密钥实现重用;

SessionTicket(RFC 5077),由服务端根据会话状态生成一个加密的ticket,并将key也发给客户端保证两端都可以对其进行解密。该机制相较sessionID的方式更加轻量级,服务端不需要存储会话状态数据,可减轻一定压力。

 

证书的校验

1. 检查数字签名;

   数字签名通过数字摘要算法生成并通过私钥加密传输,对端公钥解密;

2. CA链授权检查;

3. 证书过期及激活时间检查;

 

数字摘要的计算图示

 

关于Server Name Indication

在普通 SSL/TLS握手的过程中,客户端发送的信息之中不包括服务器的域名;因此理论上服务器只能包含一个域名,否则会分不清应该向客户端提供哪一个域名的数字证书。在后续TLS的版本中实现了SNI(Server Name Indication) 扩展,用于支持一台服务器主机需服务多个域名的场景。

由客户端请求时发送指定的域名,服务器据此选择相应证书完成握手。

 

六、参考文档

阮一峰_SSL/TLS协议运行机制的概述

An overview of the SSL or TLS handshake

 

posted @ 2016-12-25 20:56  美码师  阅读(11335)  评论(0编辑  收藏