图解SSL/TLS协议

作者: 阮一峰

日期: 2014年9月20日

本周,CloudFlare宣布,开始提供Keyless服务,即你把网站放到它们的CDN上,不用提供自己的私钥,也能使用SSL加密链接。

CloudFlare

我看了CloudFlare的说明(这里这里),突然意识到这是绝好的例子,可以用来说明SSL/TLS协议的运行机制。它配有插图,很容易看懂。

下面,我就用这些图片作为例子,配合我半年前写的《SSL/TLS协议运行机制的概述》,来解释SSL协议。

一、SSL协议的握手过程

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

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

握手阶段分成五步。

第一步,爱丽丝给出协议版本号、一个客户端生成的随机数(Client random),以及客户端支持的加密方法。

第二步,鲍勃确认双方使用的加密方法,并给出数字证书、以及一个服务器生成的随机数(Server random)。

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

第四步,鲍勃使用自己的私钥,获取爱丽丝发来的随机数(即Premaster secret)。

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

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

二、私钥的作用

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

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

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

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

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

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

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

三、DH算法的握手阶段

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

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

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

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

四、session的恢复

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

这时有两种方法可以恢复原来的session:一种叫做session ID,另一种叫做session ticket。

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

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

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

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

(完)

珠峰培训

简寻

留言(33条)

阮兄,深入浅出的讲解,很好理解了

我看了 CloudFlare 的说明(这里和这里)
两个这里是同一个链接

@c:

谢谢指出,已经改过来了。

session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。

这段话比较牵强了,有不同方案的集群session保存方案.

个人理解,这应该算是CloudFlare产品创新,相当于他能提供一个PKI正常验证体系下的证书颁发机构,这个机构可以用来为开启KeyLess服务的站颁发证书

引用xzy的发言:

这段话比较牵强了,有不同方案的集群session保存方案.


同意,现在大型应用基本上都是集群环境,session很少保存在一台服务器上。很多都是用集中式session管理

深入浅出,受教。

阮哥的每篇文章都是必看的!!

安全系列的科普文章写的真是不错,图文并茂,深入浅出,赞!

不错的文章。感觉使用SSL好烦人,证书生成什么的烦死了。

引用qianqian的发言:

个人理解,这应该算是CloudFlare产品创新,相当于他能提供一个PKI正常验证体系下的证书颁发机构,这个机构可以用来为开启KeyLess服务的站颁发证书

恩,我也想知道cloudflare怎么解决证书的网站签名问题。

阮兄的页面对手机浏览器支持不太好,现在很多人会用手机阅读,建议针对移动浏览器做一些优化

DH算法虽然无需从客户端发送pre-master key, 但server DH参数和client DH参数应该是明文发送的吧,加上前面两个随机数也是明文发送的,那第三者完全能通过抓包的办法拿到server DH,client DH以及前两个随机数,然后自己生成会话密钥。这样后续的加密通信岂不是不安全?

引用xzy的发言:

这段话比较牵强了,有不同方案的集群session保存方案.

HTTPS服务器的底层SESSION内存 很难集群。

引用xzy的发言:

这段话比较牵强了,有不同方案的集群session保存方案.

作者说的是rfc5077,是传输层TLS通信的Session。不是应用层HTTP的Session。

引用爱国者的发言:

DH算法虽然无需从客户端发送pre-master key, 但server DH参数和client DH参数应该是明文发送的吧,加上前面两个随机数也是明文发送的,那第三者完全能通过抓包的办法拿到server DH,client DH以及前两个随机数,然后自己生成会话密钥。这样后续的加密通信岂不是不安全?

这里DH算法有说,有限域内计算离散对数是几乎不可能的任务;得到这些参数是比较难算出密钥的;另外,我觉得这篇文章只说明了SSL协议使用DH算法的情况吧,在试用RSA等其他算法的时候,是不是不用再生成密钥对?服务器直接把公钥传给客户端就直接传输数据了?求解惑!

引用爱国者的发言:

DH算法虽然无需从客户端发送pre-master key, 但server DH参数和client DH参数应该是明文发送的吧,加上前面两个随机数也是明文发送的,那第三者完全能通过抓包的办法拿到server DH,client DH以及前两个随机数,然后自己生成会话密钥。这样后续的加密通信岂不是不安全?

我也有同样的困惑。后面小胜的回答,虽然听起来很专业,信度很高,但是他没有因循作者的讲解思路。

作者阮一峰的讲解思路是说采用 DH 算法,可以绕开Premaster secret被强行破解的风险:

虽然理论上,只要服务器的公钥足够长(比如2048位),那么Premaster secret可以保证不被破解。但是为了足够安全,………… 可以采用 DH 算法

而小胜的回答思路是:是说采用 DH 算法,在理论上也能保证Premaster secret不被破解,而且并没说明从理论上看【原始算法】和【DH算法】哪个更容易被强行破解。

引用杨历的发言:

作者说的是rfc5077,是传输层TLS通信的Session。不是应用层HTTP的Session。

是的,session ticket是保存在客户端的,无需在服务端保存,因为session ticket就是对话密钥和加密方法经过加密后的信息。

引用qalong的发言:


同意,现在大型应用基本上都是集群环境,session很少保存在一台服务器上。很多都是用集中式session管理


是分布式缓存吧 加上session容易丢失 使用分布式缓存是非常好的 也解决了只能在一台机子上的问题

引用pimgeek的发言:

而小胜的回答思路是:是说采用 DH 算法,在理论上也能保证Premaster secret不被破解,而且并没说明从理论上看【原始算法】和【DH算法】哪个更容易被强行破解。

这是DH算法的一个简单描述:
1) A随机产生一个大整数a,然后计算Ka=ga mod n。(a需要保密)
2) B随机产生一个大整数b,然后计算Kb=gb mod n。(b需要保密)
3) A把Ka发送给B,B把Kb发送给A
4) A计算K=Kba mod n
5) B计算K=Kab mod n
由于Kba mod n= (gb mod n)a mod n= (ga mod n)b mod n,因此可以保证双方得到的K是相同的,K即是共享的密钥。
意思是说client与server端都有一个随机数是不会通过网络传输的。所以保证了安全。
(所以感觉说明DH原理的那张图,不是很贴切,不知道自己理解对不)

如果服务器对客户端认证,而客户端不用对服务器认证,那么握手的过程应该什么样的呢?

真的好难啊,和以前的学的东西混在一起,彻底晕了!

这几张图的确说明的超级详细容易理解~ DH那里原图没有具体说明不容易被破解的原因,现在实际使用起来配合其他工具的确保密性更高。话说,看完整篇文章,只看到SSL了,没看到TLS。。。

引用gg的发言:

这几张图的确说明的超级详细容易理解~ DH那里原图没有具体说明不容易被破解的原因,现在实际使用起来配合其他工具的确保密性更高。话说,看完整篇文章,只看到SSL了,没看到TLS。。。

TLS就是SSL的升级版,原理都一样的

我想知道,既然是用DH作为共享密钥的生成和交换DH所需的随机函数,那为什么还需要第一和第二阶段的随机函数呢?

ssl的流程写的很清楚 赞一个

引用爱国者的发言:

DH算法虽然无需从客户端发送pre-master key, 但server DH参数和client DH参数应该是明文发送的吧,加上前面两个随机数也是明文发送的,那第三者完全能通过抓包的办法拿到server DH,client DH以及前两个随机数,然后自己生成会话密钥。这样后续的加密通信岂不是不安全?

CA的作用之一是来确保server的合法性 如果仅仅使用DH无法确保server的合法性,另外依旧存在被中间人攻击的可能性

引用爱国者的发言:

DH算法虽然无需从客户端发送pre-master key, 但server DH参数和client DH参数应该是明文发送的吧,加上前面两个随机数也是明文发送的,那第三者完全能通过抓包的办法拿到server DH,client DH以及前两个随机数,然后自己生成会话密钥。这样后续的加密通信岂不是不安全?

其实我也有同问,查了DH算法明白了.其实DH还是有自己的密钥,这个密钥由于计算离散对数是十分困难的,所以第三方很难破解或者说现今是不可能的.

引用xzy的发言:

这段话比较牵强了,有不同方案的集群session保存方案.

有大厂就是这种方案,需要proxy server去一个共享存储里面读取

还有几个请问下,就是如何跟源站之间协商session key,
源站的web server也需要做相应改造吧
cloudflare的做法是否已经被ssl的rfc文档接受?

第三节DH算法的握手阶段的配图,Visitor 是通过两个随机数生成的 session key,而 CloudFlare 是通过两个随机数和 Premaster secret 生成的 session key, 这两个 session key 不应该是相等的吗?不太理解,求指教。谢谢

Defined
Protocol Year
SSL 1.0 n/a
SSL 2.0 1995
SSL 3.0 1996
TLS 1.0 1999
TLS 1.1 2006
TLS 1.2 2008
TLS 1.3 TBD

敢问那个图片是用什么软件生成的

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接