图解SSL/TLS协议

标签: Developer | 发表时间:2014-09-20 10:33 | 作者:阮一峰
出处:http://www.ruanyifeng.com/blog/

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

(完)

文档信息

相关 [ssl tls] 推荐:

图解SSL/TLS协议

- - 阮一峰的网络日志
本周, CloudFlare宣布,开始提供Keyless服务,即你把网站放到它们的CDN上,不用提供自己的私钥,也能使用SSL加密链接. 我看了CloudFlare的说明( 这里和 这里),突然意识到这是绝好的例子,可以用来说明SSL/TLS协议的运行机制. 下面,我就用这些图片作为例子,配合我半年前写的 《SSL/TLS协议运行机制的概述》,来解释SSL协议.

SSL与TLS的区别以及介绍

- - 博客园_知识库
  SSL:(Secure Socket Layer,安全套接字层),位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层. SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性,以实现客户端和服务器之间的安全通讯. 该协议由两层组成:SSL记录协议和SSL握手协议.   TLS:(Transport Layer Security,传输层安全协议),用于两个应用程序之间提供保密性和数据完整性.

聊聊HTTPS和SSL/TLS协议

- - 外刊IT评论
要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识. 大致了解几个基本术语(HTTPS、SSL、TLS)的含义. 大致了解 HTTP 和 TCP 的关系(尤其是“短连接”VS“长连接”). 大致了解加密算法的概念(尤其是“对称加密与非对称加密”的区别). 考虑到很多技术菜鸟可能不了解上述背景,俺先用最简短的文字描述一下.

研究人员将演示攻击SSL/TLS

- Tim - Solidot
9月21日布宜诺斯艾利斯举行的Ekoparty安全会议上,安全研究人员Thai Duong和Juliano Rizzo将演示针对SSL/TLS的概念验证攻击. 研究人员在SSL/TLS协议中发现了严重弱点,能让黑客悄悄破译Web服务器和终端用户浏览器之间传输的加密数据. 弱点主要影响TLS协议1.0版及SSL所有版本,TLS 1.1/1.2未受影响.

Google将发布补丁阻止SSL/TLS攻击

- SotongDJ - Solidot
51开源社区 写道 "研究者最近发现了一个存在于TLS 1.0(目前使用最广泛的安全加密协议)的重大漏洞. 利用该漏洞,黑客可以悄悄解密客户端和服务器端之间通过HTTPS传输的数据. 本周在布宜诺斯艾利斯举行的黑客技术研讨会上,Thai Duong和Juliano Rizzo将展示一个利用此漏洞的方式,使用称为BEAST的脚本,配合一个网络连接嗅探器即可在30分钟内解密一个PayPal的用户Cookie.

使用 TLS/SSL 加密你的 HTTP 代理

- - 依云's Blog
HTTP 代理是明文的,这导致实际访问的 URL 可以被他人监测到. 即使使用 HTTPS 协议,经过 HTTP 代理时会发送 CONNECT请求,告诉代理要连续到远程主机的指定端口. 比如像 HTTPS 那样,使用 TLS 协议连接到代理服务器,然后再进行 HTTP 请求. 很遗憾的是,我在 ziproxy 的配置里没有发现这样的选项.

数字证书, 数字签名, SSL(TLS) , SASL .

- - CSDN博客Web前端推荐文章
因为项目中要用到TLS + SASL 来做安全认证层. 所以看了一些网上的资料, 这里做一个总结..  数字证书:  http://www.cnblogs.com/hyddd/archive/2009/01/07/1371292.html.  数字证书和SSL:  http://www.2cto.com/Article/201203/121534.html.

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

- - 阮一峰的网络日志
互联网的通信安全,建立在SSL/TLS协议之上. 本文简要介绍SSL/TLS协议的运行机制. 文章的重点是设计思想和运行过程,不涉及具体的实现细节. 如果想了解这方面的内容,请参阅 RFC文档. 不使用SSL/TLS的HTTP通信,就是不加密的通信. 所有信息明文传播,带来了三大风险. 窃听风险(eavesdropping):第三方可以获知通信内容.