前言
在上篇文章HTTPS详解一中,我已经为大家介绍了 HTTPS 的详细原理和通信流程,但总感觉少了点什么,应该是少了对安全层的针对性介绍,那么这篇文章就算是对HTTPS 详解一的补充吧。还记得这张图吧。
HTTPS 和 HTTP的区别
显然,HTTPS 相比 HTTP最大的不同就是多了一层 SSL (Secure Sockets Layer 安全套接层)或 TLS (Transport Layer Security 安全传输层协议)。有了这个安全层,就确保了互联网上通信双方的通信安全,那么这个安全层是怎么工作的,SSL / TLS
握手过程又是怎样的呢?本文将对这些问题一一解答。
SSL / TLS 以及 SSL / TLS 握手的概念
SSL 和 TLS 协议可以为通信双方提供识别和认证通道,从而保证通信的机密性和数据完整性。TLS 协议是从Netscape SSL 3.0协议演变而来的,不过这两种协议并不兼容,SSL 已经逐渐被 TLS 取代,所以下文就以 TLS 指代安全层。 TLS 握手是启动 HTTPS 通信的过程,类似于 TCP 建立连接时的三次握手。 在 TLS 握手的过程中,通信双方交换消息以相互验证,相互确认,并确立它们所要使用的加密算法以及会话密钥 (用于对称加密的密钥)。可以说,TLS 握手是 HTTPS 通信的基础部分。
TLS 握手过程中发生了什么
我们已经知道 TLS 握手的目的是建立安全连接,那么通信双方在这个过程中究竟干了什么呢?下面就是答案:
- 商定双方通信所使用的的 TLS 版本 (例如 TLS1.0, 1.2, 1.3等等);
- 确定双方所要使用的密码组合;
- 客户端通过服务器的公钥和数字证书 (上篇文章已有介绍)上的数字签名验证服务端的身份;
- 生成会话密钥,该密钥将用于握手结束后的对称加密。
TLS 握手详细过程
下面来看 TLS 握手的详细过程 (注:此图与HTTPS详解一中的 HTTPS 原理图的流程大致相同,不同的是此图把重点放在了TLS握手的相关概念上):
- “client hello"消息:客户端通过发送"client hello"消息向服务器发起握手请求,该消息包含了客户端所支持的 TLS 版本和密码组合以供服务器进行选择,还有一个"client random"随机字符串。
- “server hello"消息:服务器发送"server hello"消息对客户端进行回应,该消息包含了数字证书,服务器选择的密码组合和"server random"随机字符串。
- 验证:客户端对服务器发来的证书进行验证,确保对方的合法身份,验证过程可以细化为以下几个步骤:
- 检查数字签名
- 验证证书链 (这个概念下面会进行说明)
- 检查证书的有效期
- 检查证书的撤回状态 (撤回代表证书已失效)
- “premaster secret"字符串:客户端向服务器发送另一个随机字符串"premaster secret (预主密钥)",这个字符串是经过服务器的公钥加密过的,只有对应的私钥才能解密。
- 使用私钥:服务器使用私钥解密"premaster secret”。
- 生成共享密钥:客户端和服务器均使用 client random,server random 和 premaster secret,并通过相同的算法生成相同的共享密钥 KEY。
- 客户端就绪:客户端发送经过共享密钥 KEY加密过的"finished"信号。
- 服务器就绪:服务器发送经过共享密钥 KEY加密过的"finished"信号。
- 达成安全通信:握手完成,双方使用对称加密进行安全通信。
TLS 握手过程中的一些重要概念
-
数字证书 (digital certificate):在非对称加密通信过程中,服务器需要将公钥发送给客户端,在这一过程中,公钥很可能会被第三方拦截并替换,然后这个第三方就可以冒充服务器与客户端进行通信,这就是传说中的“中间人攻击”(man in the middle attack)。解决此问题的方法是通过受信任的第三方交换公钥,具体做法就是服务器不直接向客户端发送公钥,而是要求受信任的第三方,也就是证书认证机构 (Certificate Authority, 简称 CA)将公钥合并到数字证书中,然后服务器会把公钥连同证书一起发送给客户端,私钥则由服务器自己保存以确保安全。数字证书一般包含以下内容:
- 证书所有者的公钥
- 证书所有者的专有名称
- 证书颁发机构的专有名称
- 证书的有效起始日期
- 证书的过期日期
- 证书数据格式的版本号
- 序列号,这是证书颁发机构为该证书分配的唯一标识符
- … …
-
数字签名 (digital signature):这个概念很好理解,其实跟人的手写签名类似,是为了确保数据发送者的合法身份,也可以确保数据内容未遭到篡改,保证数据完整性。与手写签名不同的是,数字签名会随着文本数据的变化而变化。具体到数字证书的应用场景,数字签名的生成和验证流程如下:
- 服务器对证书内容进行信息摘要计算 (常用算法有 SHA-256等),得到摘要信息,再用私钥把摘要信息加密,就得到了数字签名
- 服务器把数字证书连同数字签名一起发送给客户端
- 客户端用公钥解密数字签名,得到摘要信息
- 客户端用相同的信息摘要算法重新计算证书摘要信息,然后对这两个摘要信息进行比对,如果相同,则说明证书未被篡改,否则证书验证失败
-
证书链 (certificate chain):证书链,也称为证书路径,是用于认证实体合法身份的证书列表,具体到 HTTPS 通信中,就是为了验证服务器的合法身份。之所以使用证书链,是为了保证根证书 (root CA certificate)的安全,中间层可以看做根证书的代理,起到了缓冲的作用,如下图所示,这里还以 B 站证书为例:
证书链从根证书开始,并且证书链中的每一级证书所标识的实体都要为其下一级证书签名,而根证书自身则由证书颁发机构签名。客户端在验证证书链时,必须对链中所有证书的数字签名进行验证,直到达到根证书为止。
-
密码规范和密码组合 (CipherSpecs 和 CipherSuites):通信双方在安全连接中所使用的算法必须符合密码安全协议的规定,CipherSpecs 和 CipherSuites 正好定义了合法的密码算法组合。CipherSpecs 用于认证加密算法和信息摘要算法的组合,通信双方必须同意这个密码规范才能进行通信。而 CipherSuites 则定义了 SSL / TLS 安全连接中所使用的加密算法的组合,该组合包含三种不同的算法:
- 握手期间所使用的的密钥交换和认证算法 (最常用的是 RSA 算法)
- 加密算法 (用于握手完成后的对称加密,常用的有 AES、3DES等)
- 信息摘要算法 (常用的有 SHA-256、SHA-1 和 MD5 等)
总结
本文对 SSL / TLS 握手过程进行了详细的解析,也对握手过程中的几个重要概念进行了补充说明。想继续深入了解的小伙伴可以去参考一下 CloudFlare 和 IBM 的官网,这两个网站也是本文内容的主要来源。多逛逛英文网站,不仅可以涨姿势,获取权威信息,还能顺带提升一波英语水平,一举两得,岂不美哉,希望小伙伴们也能尽快养成这样的好习惯。HTTPS 详解部分到此结束,咱们下篇文章再见。