SSL/TLS协议运行机制

SSL(“Secure Sockets Layer” 安全套接层)/TLS(“Transport Layer Security” 传输层安全协议)的基本思路采用的是公钥加密算法,原理:

        客户端向服务器发送获取公钥的请求,服务端生成公钥和私钥,将公钥返回给客户端(这儿过程中请求和返回数据都是明文);下次客户端发送请求用公钥加密,服务端用私钥解密客户端的请求数据

在这个过程中将存在两个问题:

1、如何保证公钥不会被篡改?

将公钥放在数字证书中,只要数字证书没有被篡改就公钥就安全。

2、如何减少每次请求的时长(每一次请求都需要先获取公钥)?

每一次对话,客户端与服务端约定好对话密钥,对话密钥是对称加密的,运算速度会非常的快,用它加密请求信息。

服务器的公钥将只用于获取对话密钥本身,以减少加密算法所消耗的时长。

SSL/TLS协议的基本过程:(1、2两步又称为握手阶段)

       1. 客户端向服务端索要公钥、验证公钥的合法性

       2. 双方约定对话密钥

       3. 双方通过对话密钥进行信息加密


握手阶段的详细过程

       一、客户端首次请求(Client Hello)

            第一步是客户端向服务端发送Client Hello消息,消息内容:

      支持的协议版本号(SSL Version)

      客户端生成的随机数(Client Random1)

      客户端支持的加密套件(Support Ciphers)比如:RSA加密算法、DH加密算法

      支持的压缩算法

      支持的一些SSL/TLS扩展 (sever_name等)      

SSL/TLS协议运行机制_第1张图片

SSL Version,用于服务端验证支持的协议版本号。  Client Random1,随机数用于后面对话密钥的生成。  Support Ciphers,用于服务端选择支持的加密算法。 压缩算法,用于压缩的算法。

客户端请求中原本是不包括服务器域名的,也就是说,理论上只能包含一个服务器,对于支持多个虚拟机的服务器来说,这并不方便,不能知道向哪个服务器请求证书。为了解决这个问题,在Client Hello报文中了,扩展信息中,增加了sever_name这个扩展信息,通过域名进行区分。

      二、服务器回应(Sever Hello、Certificate、Server Key Exchange、Server Hello Done)         

           服务端收到客户端的请求之后向客户端返回数据:      

     确定加密通信使用的通信版本               

     服务端生成的随机数(Sever Random)

     确定双方使用的加密算法和压缩算法

     支持的一些SSL/TLS扩展

SSL/TLS协议运行机制_第2张图片

          服务器发送Sever Hello后,向客户端发送证书信息(Certificate)

    服务器证书(Certificate)

SSL/TLS协议运行机制_第3张图片

          服务器发送Certificate后,开始发送sever key exchange,向客户端发送生成密钥的信息。这个发送只限于使用DH算法(DH算法生成的密钥是由客户端参数和服务端参数根据规则计算得出),如果是RSA算法不需要发送此请求。

    服务器DH参数(Sever Key Exchange)

          当服务器发送Sever Hello Done,表明所有的参数发送完成。

SSL/TLS协议运行机制_第4张图片

PS:此为单向验证,若是双向验证,需要在Sever Hello Done之前发送Certificate Request,表示需要客户端提供证书,内容为:

     客户端应当提供的证书类型

     服务端可以接受的证书列表

      三、客户端回应(Client Key Exchange、 Change Chiper Spec、Encrypted Handshake Message

          客户端接收到服务器的证书之后,将对接收到的证书进行校验,若发现证书不是可信机构颁发或者域名不正确、证书已过期,将由客户端进行选择是否继续。若证书没有问题向服务端发送消息:

    客户端Client Key Exchange生成的一个随机数(Pre Master Secret)

    客户端传输改变通知(Change Chiper Spec)

    客户端第一个加密报文(Encrypted Handshake Message)

Client Key Exchange生成一个随机数,如果采用的是RSA加密方式则取出证书中的公钥,生成随机数。如果采用的是DH算法则使用双发的DH加密参数和规则生成随机数。Change Chiper Spec,通知服务端以后报文按照协商的加密方式传输。Encrypted Handshake Message,通过前两次的随机数以及最后一次的随机数(Pre Master Secret)使用确定的加密算法生成对话密钥  (Session Secret),使用对话密钥加密报文。

SSL/TLS协议运行机制_第5张图片
Client Key Exchange
SSL/TLS协议运行机制_第6张图片
Change Chiper Spec
SSL/TLS协议运行机制_第7张图片
Encrypted Handshake Message

PS:如果是双向认证,客户端还会Certificate和Certificate Verify报文。Certificate是客户端的证书,Certificate Verify是客户端拥有的所有握手过程中的签名信息。服务端对证书以及信息进行确认,如果发现证书和信息有误则终止SSL/TLS连接。

      四、服务端最后回应(New Session Ticket, Change Chiper Spec, Encrypted Handshake Message

          服务端收到客户端的加密报文之后进行解密和校验,若成功生成一个session ticket(解释见下文)。然后作出回应:

    服务端传输改变通知(Change Chiper Spec)

    服务端第一个加密报文(Encrypted Handshake Message)

SSL/TLS协议运行机制_第8张图片

Change Chiper Spec与客户端发送的含义一致,通知客户端。 Encrypted Handshake Message与客户端发送的第一报文含义一致,用于客户端进行报文验证。

客户端确定密钥以及验证成功之后,整个握手过程就基本完成,以后的报文都是通过协商好的密钥进行加密。

会话恢复(session ID 和 session ticket)

session ID

        Session Identifier(会话标识符),是 TLS 握手中生成的 Session ID。服务端可以将 Session ID 协商后的信息存起来,浏览器也可以保存 Session ID,并在后续的 ClientHello 握手中带上它,如果服务端能找到与之匹配的信息,就可以完成一次快速握手。

session ticket

        Session Identifier 机制有一些弊端,例如:1)负载均衡中,多机之间往往没有同步 Session 信息,如果客户端两次请求没有落在同一台机器上就无法找到匹配的信息;2)服务端存储 Session ID 对应的信息不好控制失效时间,太短起不到作用,太长又占用服务端大量资源。

         而 Session Ticket(会话记录单)可以解决这些问题,Session Ticket 是用只有服务端知道的安全密钥加密过的会话信息,最终保存在浏览器端。浏览器如果在 ClientHello 时带上了 Session Ticket,只要服务器能成功解密就可以完成快速握手。

简单的描述了下会话恢复,SSL/TLS优化请参考这篇文章 

参考资料

SSL/TLS协议运行机制的概述 

SSL/TLS 握手 

你可能感兴趣的:(SSL/TLS协议运行机制)