作者：阮一峰
日期：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条）
瑞意说：
阮兄，深入浅出的讲解，很好理解了
c说：
我看了 CloudFlare 的说明（这里和这里）
两个这里是同一个链接
阮一峰说：
@c：
谢谢指出，已经改过来了。
xzy说：
session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。
这段话比较牵强了,有不同方案的集群session保存方案.
qianqian说：
个人理解，这应该算是CloudFlare产品创新，相当于他能提供一个PKI正常验证体系下的证书颁发机构，这个机构可以用来为开启KeyLess服务的站颁发证书
qalong说：
引用xzy的发言：
这段话比较牵强了,有不同方案的集群session保存方案.
同意，现在大型应用基本上都是集群环境，session很少保存在一台服务器上。很多都是用集中式session管理
林晨说：
深入浅出，受教。
zjhiphop说：
阮哥的每篇文章都是必看的！！
ciciywg说：
安全系列的科普文章写的真是不错，图文并茂，深入浅出，赞！
hilyb说：
不错的文章。感觉使用SSL好烦人，证书生成什么的烦死了。
xiongxiong说：
引用qianqian的发言：
个人理解，这应该算是CloudFlare产品创新，相当于他能提供一个PKI正常验证体系下的证书颁发机构，这个机构可以用来为开启KeyLess服务的站颁发证书
恩，我也想知道cloudflare怎么解决证书的网站签名问题。
铜矿说：
阮兄的页面对手机浏览器支持不太好,现在很多人会用手机阅读,建议针对移动浏览器做一些优化
爱国者说：
DH算法虽然无需从客户端发送pre-master key, 但server DH参数和client
DH参数应该是明文发送的吧，加上前面两个随机数也是明文发送的，那第三者完全能通过抓包的办法拿到server DH，client
DH以及前两个随机数，然后自己生成会话密钥。这样后续的加密通信岂不是不安全？
xoxo说：
引用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等其他算法的时候，是不是不用再生成密钥对？服务器直接把公钥传给客户端就直接传输数据了？求解惑！
pimgeek说：
引用爱国者的发言：
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容易丢失 使用分布式缓存是非常好的 也解决了只能在一台机子上的问题
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原理的那张图，不是很贴切，不知道自己理解对不）
aya说：
如果服务器对客户端认证，而客户端不用对服务器认证，那么握手的过程应该什么样的呢？
WT说：
真的好难啊，和以前的学的东西混在一起，彻底晕了！
gg说：
这几张图的确说明的超级详细容易理解~ DH那里原图没有具体说明不容易被破解的原因，现在实际使用起来配合其他工具的确保密性更高。话说，看完整篇文章，只看到SSL了，没看到TLS。。。
御剑飞星说：
引用gg的发言：
这几张图的确说明的超级详细容易理解~ DH那里原图没有具体说明不容易被破解的原因，现在实际使用起来配合其他工具的确保密性更高。话说，看完整篇文章，只看到SSL了，没看到TLS。。。
TLS就是SSL的升级版，原理都一样的
鬼知道说：
我想知道，既然是用DH作为共享密钥的生成和交换DH所需的随机函数，那为什么还需要第一和第二阶段的随机函数呢？
Edem说：
ssl的流程写的很清楚 赞一个
byronhe说：
https://blog.helong.info/blog/2015/09/06/tls-protocol-analysis-and-crypto-protocol-design/
供参考
mk说：
引用爱国者的发言：
DH算法虽然无需从客户端发送pre-master key, 但server DH参数和client
DH参数应该是明文发送的吧，加上前面两个随机数也是明文发送的，那第三者完全能通过抓包的办法拿到server DH，client
DH以及前两个随机数，然后自己生成会话密钥。这样后续的加密通信岂不是不安全？
CA的作用之一是来确保server的合法性 如果仅仅使用DH无法确保server的合法性，另外依旧存在被中间人攻击的可能性
bobjiao说：
引用爱国者的发言：
DH算法虽然无需从客户端发送pre-master key, 但server DH参数和client
DH参数应该是明文发送的吧，加上前面两个随机数也是明文发送的，那第三者完全能通过抓包的办法拿到server DH，client
DH以及前两个随机数，然后自己生成会话密钥。这样后续的加密通信岂不是不安全？
其实我也有同问,查了DH算法明白了.其实DH还是有自己的密钥,这个密钥由于计算离散对数是十分困难的,所以第三方很难破解或者说现今是不可能的.
load说：
引用xzy的发言：
这段话比较牵强了,有不同方案的集群session保存方案.
有大厂就是这种方案，需要proxy server去一个共享存储里面读取
还有几个请问下，就是如何跟源站之间协商session key，
源站的web server也需要做相应改造吧
cloudflare的做法是否已经被ssl的rfc文档接受？
字节流说：
第三节DH算法的握手阶段的配图，Visitor 是通过两个随机数生成的 session key，而 CloudFlare 是通过两个随机数和 Premaster secret 生成的 session key, 这两个 session key 不应该是相等的吗？不太理解，求指教。谢谢
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
别扭的键盘说：
敢问那个图片是用什么软件生成的
董光金说：
写的很好，很美！大赞一个
mactec说：
阮老师
DH算法实际在TLS/SSL部署中并没有RSA可靠，原因在于RSA的主要风险在于服务器私钥丢失后的第三方监听攻击
而DH算法本身有缺陷，中间人攻击更为常见，导致其实更为少用
pure说：
大图不知道是挂了还是要VPN啊
振宇说：
引用mactec的发言：
阮老师
DH算法实际在TLS/SSL部署中并没有RSA可靠，原因在于RSA的主要风险在于服务器私钥丢失后的第三方监听攻击
而DH算法本身有缺陷，中间人攻击更为常见，导致其实更为少用
朋友我对你的说法稍有异议，Server端的私钥丢失这个属于很大的故障了吧？
我认为RSA算法的缺陷就是无法证明共匙被替换后，导致的中间人攻击问题。而DH算法本身也是无法避免中间人攻击问题的，所以在上面的实例图中，阮老师加入了数字证书的逻辑。无论是RSA还是DH都需要客户端通过CA的公共钥匙解析到数字证书中存在的server端公钥（rsa），说明一下这边DH算法传递的公共数据我们也可当公钥来看（理解方便）。
另外想请教一下层主，为什么DH更容易被中间人攻击？
