深入解析SSL/TLS协议

     最初SSL协议是由netscape开发，并集成到浏览器中，用于保护HTTP传输安全性，作为在传输层和应用层之间的一层，对更多的需要保护数据安全性的协议进行封装。IETF以SSL协议为基础，提出了一种新的协议：TLS，建立在SSLV3.0的基础上，是SSL3.0的后续版本，已经开始在实际应用中使用。

一、SSL协议的握手过程

　　开始加密通信之前，客户端和服务器首先必须建立连接和交换参数，这个过程叫做握手（handshake）。

　　假定客户端叫做爱丽丝，服务器叫做鲍勃，整个握手过程可以用下图说明（点击看大图）。

　　握手阶段分成五步

　　第一步，爱丽丝给出协议版本号、一个客户端生成的随机数（Clientrandom），以及客户端支持的加密方法。

　　第二步，鲍勃确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Serverrandom）。

　　第三步，爱丽丝确认数字证书有效，然后生成一个新的随机数（Premastersecret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。

　　第四步，鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premastersecret）。

　　第五步，爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（sessionkey），用来加密接下来的整个对话过程。

　　上面的五步，画成一张图，就是下面这样。

　　二、私钥的作用

　　握手阶段有三点需要注意。

　　（1）生成对话密钥一共需要三个随机数。

　　（2）握手之后的对话使用"对话密钥"加密（对称加密），服务器的公钥和私钥只用于加密和解密"对话密钥"（非对称加密），无其他作用。

　　（3）服务器公钥放在服务器的数字证书之中。

　　从上面第二点可知，整个对话过程中（握手阶段和其后的对话），服务器的公钥和私钥只需要用到一次。这就是CloudFlare能够提供Keyless服务的根本原因。

　　某些客户（比如银行）想要使用外部CDN，加快自家网站的访问速度，但是出于安全考虑，不能把私钥交给CDN服务商。这时，完全可以把私钥留在自家服务器，只用来解密对话密钥，其他步骤都让CDN服务商去完成。

　　上图中，银行的服务器只参与第四步，后面的对话都不再会用到私钥了。

　　三、DH算法的握手阶段

　　整个握手阶段都不加密（也没法加密），都是明文的。因此，如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数（Premastersecret）能不能被破解。

　　虽然理论上，只要服务器的公钥足够长（比如2048位），那么Premastersecret可以保证不被破解。但是为了足够安全，我们可以考虑把握手阶段的算法从默认的RSA算法，改为Diffie-Hellman算法（简称DH算法）。

　　协议结构

　　TLS协议包括两个协议组――TLS记录协议和TLS握手协议――每组具有很多不同格式的信息。在此文件中我们只列出协议摘要并不作具体解析。具体内容可参照相关文档。

　　TLS记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用MAC、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。

　　TLS连接状态指的是TLS记录协议的操作环境。它规定了压缩算法、加密算法和MAC算法。

　　TLS记录层从高层接收任意大小无空块的连续数据。密钥计算：记录协议通过算法从握手协议提供的安全参数中产生密钥、IV和MAC密钥。TLS握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。

　　采用DH算法后，Premastersecret不需要传递，双方只要交换各自的参数，就可以算出这个随机数。

　　上图中，第三步和第四步由传递Premastersecret变成了传递DH算法所需的参数，然后双方各自算出Premastersecret。这样就提高了安全性。

　　四、session的恢复

　　握手阶段用来建立SSL连接。如果出于某种原因，对话中断，就需要重新握手。

　　这时有两种方法可以恢复原来的session：一种叫做sessionID，另一种叫做sessionticket。

　　sessionID的思想很简单，就是每一次对话都有一个编号（sessionID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的"对话密钥"，而不必重新生成一把。

　　上图中，客户端给出sessionID，服务器确认该编号存在，双方就不再进行握手阶段剩余的步骤，而直接用已有的对话密钥进行加密通信。

　　sessionID是目前所有浏览器都支持的方法，但是它的缺点在于sessionID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。sessionticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。

　　上图中，客户端不再发送sessionID，而是发送一个服务器在上一次对话中发送过来的sessionticket。这个sessionticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到sessionticket以后，解密后就不必重新生成对话密钥了。

     SSL的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证，本实例中只有客户端验证服务端，服务端并没有对客户端进行验证，一般相互进行身份认证的情况在登录银行系统时会用到。

更多详细内容尽在编程学习网哟~