(转)图解SSL/TLS协议

作者:阮一峰

日期:2014年9月20日

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

我看了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以后,解密后就不必重新生成对话密钥了。

(完)

留言(37条)

瑞意说:

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

2014年9月20日 18:58|#|引用

c说:

我看了 CloudFlare 的说明(这里和这里)

两个这里是同一个链接

2014年9月21日 16:31|#|引用

阮一峰说:

@c:

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

2014年9月21日 18:53|#|引用

xzy说:

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

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

2014年9月22日 10:28|#|引用

qianqian说:

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

2014年9月22日 15:13|#|引用

qalong说:

引用xzy的发言:

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

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

2014年9月22日 15:57|#|引用

林晨说:

深入浅出,受教。

2014年9月23日 09:17|#|引用

zjhiphop说:

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

2014年9月23日 10:28|#|引用

ciciywg说:

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

2014年9月23日 10:39|#|引用

hilyb说:

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

2014年9月23日 17:34|#|引用

xiongxiong说:

引用qianqian的发言:

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

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

2014年9月25日 10:07|#|引用

铜矿说:

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

2014年9月26日 15:26|#|引用

爱国者说:

DH算法虽然无需从客户端发送pre-master key, 但server DH参数和client

DH参数应该是明文发送的吧,加上前面两个随机数也是明文发送的,那第三者完全能通过抓包的办法拿到server DH,client

DH以及前两个随机数,然后自己生成会话密钥。这样后续的加密通信岂不是不安全?

2014年10月 7日 11:25|#|引用

xoxo说:

引用xzy的发言:

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

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

2014年10月13日 14:18|#|引用

杨历说:

引用xzy的发言:

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

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

2014年10月22日 21:23|#|引用

小胜说:

引用爱国者的发言:

DH算法虽然无需从客户端发送pre-master key, 但server DH参数和client

DH参数应该是明文发送的吧,加上前面两个随机数也是明文发送的,那第三者完全能通过抓包的办法拿到server DH,client

DH以及前两个随机数,然后自己生成会话密钥。这样后续的加密通信岂不是不安全?

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

2014年11月 2日 15:17|#|引用

pimgeek说:

引用爱国者的发言:

DH算法虽然无需从客户端发送pre-master key, 但server DH参数和client

DH参数应该是明文发送的吧,加上前面两个随机数也是明文发送的,那第三者完全能通过抓包的办法拿到server DH,client

DH以及前两个随机数,然后自己生成会话密钥。这样后续的加密通信岂不是不安全?

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

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

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

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

2014年11月30日 00:38|#|引用

贾岛说:

引用杨历的发言:

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

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

2014年12月 5日 16:46|#|引用

不经夸说:

引用qalong的发言:

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

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

2014年12月 8日 10:55|#|引用

ranger_ray说:

引用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原理的那张图,不是很贴切,不知道自己理解对不)

2014年12月13日 23:15|#|引用

aya说:

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

2015年1月 8日 13:20|#|引用

WT说:

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

2015年1月24日 14:32|#|引用

gg说:

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

2015年4月10日 10:00|#|引用

御剑飞星说:

引用gg的发言:

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

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

2015年4月29日 18:31|#|引用

鬼知道说:

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

2015年7月20日 23:01|#|引用

Edem说:

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

2015年8月14日 12:55|#|引用

byronhe说:

https://blog.helong.info/blog/2015/09/06/tls-protocol-analysis-and-crypto-protocol-design/

供参考

2015年9月 9日 18:27|#|引用

mk说:

引用爱国者的发言:

DH算法虽然无需从客户端发送pre-master key, 但server DH参数和client

DH参数应该是明文发送的吧,加上前面两个随机数也是明文发送的,那第三者完全能通过抓包的办法拿到server DH,client

DH以及前两个随机数,然后自己生成会话密钥。这样后续的加密通信岂不是不安全?

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

2015年12月23日 20:23|#|引用

bobjiao说:

引用爱国者的发言:

DH算法虽然无需从客户端发送pre-master key, 但server DH参数和client

DH参数应该是明文发送的吧,加上前面两个随机数也是明文发送的,那第三者完全能通过抓包的办法拿到server DH,client

DH以及前两个随机数,然后自己生成会话密钥。这样后续的加密通信岂不是不安全?

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

2016年1月 4日 13:36|#|引用

load说:

引用xzy的发言:

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

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

还有几个请问下,就是如何跟源站之间协商session key,

源站的web server也需要做相应改造吧

cloudflare的做法是否已经被ssl的rfc文档接受?

2016年4月14日 11:50|#|引用

字节流说:

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

2016年6月14日 01:05|#|引用

xgqfrms说:

Defined

ProtocolYear

SSL 1.0n/a

SSL 2.01995

SSL 3.01996

TLS 1.01999

TLS 1.12006

TLS 1.22008

TLS 1.3TBD

2016年7月11日 22:55|#|引用

别扭的键盘说:

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

2016年9月 7日 18:15|#|引用

董光金说:

写的很好,很美!大赞一个

2016年10月17日 17:29|#|引用

mactec说:

阮老师

DH算法实际在TLS/SSL部署中并没有RSA可靠,原因在于RSA的主要风险在于服务器私钥丢失后的第三方监听攻击

而DH算法本身有缺陷,中间人攻击更为常见,导致其实更为少用

2016年11月 3日 11:25|#|引用

pure说:

大图不知道是挂了还是要VPN啊

2016年11月 3日 14:34|#|引用

振宇说:

引用mactec的发言:

阮老师

DH算法实际在TLS/SSL部署中并没有RSA可靠,原因在于RSA的主要风险在于服务器私钥丢失后的第三方监听攻击

而DH算法本身有缺陷,中间人攻击更为常见,导致其实更为少用

朋友我对你的说法稍有异议,Server端的私钥丢失这个属于很大的故障了吧?

我认为RSA算法的缺陷就是无法证明共匙被替换后,导致的中间人攻击问题。而DH算法本身也是无法避免中间人攻击问题的,所以在上面的实例图中,阮老师加入了数字证书的逻辑。无论是RSA还是DH都需要客户端通过CA的公共钥匙解析到数字证书中存在的server端公钥(rsa),说明一下这边DH算法传递的公共数据我们也可当公钥来看(理解方便)。

另外想请教一下层主,为什么DH更容易被中间人攻击?

2016年11月28日 15:52|#|引用

推荐阅读更多精彩内容