为什么要有 HTTPS?简单的回答是:“因为 HTTP 不安全”。HTTP 怎么不安全呢?
只有同时具备了机密性、完整性、身份认证、不可否认这四个特性,才能算得上是安全的通信。
HTTPS 使用 HTTP 进行通信,并使用 SSL/TLS 为 HTTP 增加了机密性、完整性、身份认证、不可否认这四大安全特性。
SSL 即安全套接层(Secure Sockets Layer)。
SSL 发展到 v3 时已经证明了它是一个非常好的安全通信协议,于是互联网工程组 IETF 在 1999 年把 SSL 改名为 TLS(传输层安全,Transport Layer Security),正式标准化,版本号从 1.0 重新算起,所以 TLS1.0 实际上就是 SSLv3.1。
至今,TLS 已经发展出了三个版本,分别是 2006 年的 1.1、2008 年的 1.2 和 2018 的 1.3,每个新版本都紧跟密码学的发展和互联网的现状,持续强化安全和性能。目前应用最广泛的 TLS 版本是 1.2,而之前的版本(TLS1.1 / 1.0、SSLv3 / v2)都已经被认为是不安全的。
TLS 综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。非对称加密在这个场景中发挥的作用是 “密钥协商”,通信的双方协商得到会话密钥。会话密钥用于 HTTP 报文的加解密,以实现机密性。
TLS 由记录协议、握手协议、警报协议、变更密码规范协议、扩展协议等几个子协议组成:
通信的双方在 TLS 握手的过程中会协商使用的密码套件(cipher suite,也被称为加密套件)。
TLS 的密码套件命名非常规范。固定的格式是:“密钥交换算法 + 签名算法 + 对称加密算法 + 分组模式 + 消息摘要算法”,例如 “ECDHE-RSA-AES256-GCM-SHA384” 密码套件的意思就是:
**密钥交换算法使用的是:ECDHE。**通信的双方在 TLS 握手的过程中协商 TLS 的版本号、密码套件,交换随机数、数字证书和密钥参数,通信的双方使用 ECDHE 算法算法 “Pre Master Secret”。
**签名算法使用的是:RSA。**TLS 握手的过程中,使用 RSA 签名算法进行数字签名。服务器给浏览器发送 “Server Key Exchange” 消息,服务器对密钥参数(消息中的 Public 参数)进行数字签名,然后把签名值一并发送给浏览器。浏览器收到 “Server Key Exchange” 消息后,使用数字证书中的公钥对密钥参数(消息中的 Public 参数)进行验签。
对称加密算法使用的是:AES-256。TLS 握手后的通信使用 AES 对称加密算法进行加密,以实现机密性。对称密钥的长度 256 位
**分组模式使用的是:GCM。**加密明文的长度不固定,而一次对称加密只能处理特定长度的一块数据,这就需要进行迭代,以便将一段很长的数据全部加密,而迭代的方法就是分组模式。
**消息摘要算法使用的是:SHA-384。**TLS 握手的过程中,两次用到了该消息摘要算法。一次是:“PRF” 通过消息摘要算法,根据三个随机数(Client Random、Server Random 和 Pre Master Secret)计算主密钥 “Master Secret” 的值。另一次是:通信的双方给对方发送 “Finished” 消息。一方对之前发送的数据做摘要,再使用会话密钥对摘要进行对称加密,让对方进行验证(类似数字签名的验签)。TLS 握手后的通信使用该消息摘要算法进行消息认证,防止消息被篡改。
使用 HTTPS 协议通信,通信的双方会先建立 TCP 连接,然后执行 TLS 握手,之后就可以在安全的通信环境里收发 HTTP 请求和响应了。
执行 TLS 握手的目的是:通信的双方安全的协商会话密钥。会话密钥用于 HTTP 报文的加解密,以实现机密性。
TLS1.2 握手可以划分为两种方式:使用 RSA 算法实现密钥交换 和 使用 ECDHE 算法实现密钥交换。
下面说的是使用 ECDHE 算法实现密钥交换的 TLS 握手过程。
TLS 握手过程的简要描述:通信的双方在 TLS 握手的过程中协商 TLS 的版本号、密码套件,交换随机数、数字证书和密钥参数,最终通信的双方协商得到会话密钥。“Hello” 消息交换随机数,“Key Exchange” 消息交换密钥参数。
TLS 握手的过程如下图所示,其中每一个框都是一个记录,多个记录组合成一个 TCP 包发送。所以,最多经过两次消息往返(4 个消息,或者说 4 个 TCP 包)就可以完成 TLS 握手。
浏览器与服务器建立 TCP 连接之后,浏览器会首先给服务器发送 “Client Hello” 消息。“Client Hello” 消息携带几个参数:Version、Random、Cipher Suites。
Handshake Protocol: Client HelloVersion: TLS 1.2 (0x0303)Random: 1cbf803321fd2623408dfe…Cipher Suites (17 suites)Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
服务器收到浏览器发送的 “Client Hello” 消息后,服务器给浏览器发送 “Server Hello” 消息。“Server Hello” 消息携带几个参数:Version、Random、Cipher Suite。
Handshake Protocol: Server HelloVersion: TLS 1.2 (0x0303)Random: 0e6320f21bae50842e96…Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
服务器为了向浏览器证明自己的身份,服务器给浏览器发送一个证书链,包含了两个证书。一个是 CA 机构颁发的数字证书,另一个是 CA 机构的数字证书。
通过引入数字证书,实现了服务器的身份认证功能,这样即便黑客伪造了服务器,但是由于数字证书是没有办法伪造的,所以黑客依然无法欺骗用户。
由于服务器选择了使用 ECDHE 密钥交换算法,因此服务器需要给浏览器发送【服务端的椭圆曲线的公钥】(Server Params)。为了防止公钥被第三方篡改、被黑客冒充,服务器会对公钥进行数字签名,然后把签名值一并发送给浏览器。浏览器收到后,使用数字证书中的公钥对密钥参数(消息中的 Public 参数)进行验签。
服务器给浏览器发送 “Server Key Exchange” 消息。“Server Key Exchange” 消息携带几个参数:Curve Type、Named Curve、Pubkey、Signature Algorithm、Signature。
Handshake Protocol: Server Key ExchangeEC Diffie-Hellman Server ParamsCurve Type: named_curve (0x03)Named Curve: x25519 (0x001d)Pubkey: 3b39deaf00217894e...Signature Algorithm: rsa_pkcs1_sha512 (0x0601)Signature: 37141adac38ea4...
服务器给浏览器发送 “Server Key Exchange” 消息之后,服务器发送信息完毕。服务器给浏览器发送 “Server Hello Done” 消息,服务器向浏览器说明:服务器发送信息完毕了。
至此,第一个消息往返就结束了(2 个消息,或者说 2 个 TCP 包)。结果是:通信的双方通过明文传输共享了如下信息:浏览器生成的随机数(Client Random)、服务器生成的随机数(Server Random)、使用的椭圆曲线的类型、服务端的椭圆曲线的公钥(Server Params)。
浏览器收到服务器发送的数字证书之后,浏览器需要验证数字证书是否合法、有效。
浏览器验证完数字证书合法、有效后,浏览器再用数字证书中的公钥验证【服务器给浏览器发送的 “Server Key Exchange” 消息】的签名,以确认服务器的身份。
浏览器确认了服务器的身份之后,就开始了第二个消息往返。
由于通信的双方协商的使用 ECDHE 密钥交换算法。因此浏览器需要给服务器发送【客户端的椭圆曲线的公钥】(Client Params)。浏览器给服务器发送 “Client Key Exchange” 消息。
Handshake Protocol: Client Key ExchangeEC Diffie-Hellman Client ParamsPubkey: 8c674d0e08dc27b5eaa…
至此,通信的双方都获取到了 ECDHE 密钥交换算法需要的两个参数(Client Params、Server Params),于是通信的双方就使用 ECDHE 算法算出一个随机数,这个随机数被叫做 “Pre Master Secret”。
ECDHE 算法可以保证:即使黑客截获了之前的参数,黑客也绝对算不出这个 “Pre Master Secret” 随机数,因为 “Pre Master Secret” 的计算还使用了椭圆曲线的私钥。
目前,通信的双方已知三个随机数:Client Random、Server Random 和 Pre Master Secret。通信的双方使用这三个随机数作为原始信息,通过 PRF 算出主密钥(Master Secret)。因为黑客拿不到 “Pre Master Secret”,所以黑客也就无法得到主密钥。
主密钥 “Master Secret” 的计算:这里的 “PRF” 就是伪随机数函数,它基于密码套件里的最后一个参数(消息摘要算法),比如 SHA384。“PRF” 通过 SHA384 消息摘要算法再一次强化 “Master Secret” 的随机性。
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)
主密钥的长度为 48 字节,但是主密钥并不是最终用于通信的会话密钥,还会再用 PRF 扩展出更多的密钥,比如浏览器发送用的会话密钥(client_write_key)、服务器发送用的会话密钥(server_write_key)等,避免只用一个密钥带来的安全隐患。有了主密钥和派生的会话密钥,TLS 握手就快结束了。
浏览器给服务器发送 “Change Cipher Spec” 消息。浏览器告诉服务器:浏览器后续传输的都是对称密钥加密的密文。浏览器给服务器发送 “Finished” 消息。浏览器对之前发送的数据做摘要,再使用会话密钥对摘要进行对称加密,让服务器进行验证(类似数字签名的验签)。
服务器也进行和浏览器同样的操作。
双方都验证成功,握手正式结束,之后就可以正常收发被加密的 HTTP 请求和响应了。
TLS1.2 握手可以划分为两种方式:使用 RSA 算法实现钥交换 和 使用 ECDHE 算法实现密钥交换。
上面说了【使用 ECDHE 算法实现密钥交换的 TLS 握手过程】,下面说【使用 RSA 算法实现密钥交换的 TLS 握手过程】。
TLS 握手过程的简要描述:通信的双方在 TLS 握手的过程中协商 TLS 的版本号、密码套件,交换随机数、数字证书和密钥参数,最终通信的双方协商得到会话密钥。“Hello” 消息交换随机数,“Key Exchange” 消息交换 “Pre Master Secret”。
【使用 RSA 算法实现钥交换的 TLS 握手过程】的大体流程没有变,只是 “Pre Master Secret” 不再需要通信的双方根据密钥参数使用算法算出,而是由浏览器生成,浏览器再使用服务器的公钥对生成的 “Pre Master Secret” 进行加密。然后,浏览器给服务器发送 “Server Key Exchange” 消息,把加密后的 “Pre Master Secret” 发送给服务器。服务器收到浏览器发送的 “Server Key Exchange” 消息后,使用服务器的私钥解密出随机数 “Pre Master Secret”。
这样通信的双方也已知三个随机数:Client Random、Server Random 和 Pre Master Secret,就可以生成主密钥了。
23 | HTTPS是什么?SSL/TLS又是什么? (geekbang.org)
26 | 信任始于握手:TLS1.2连接过程解析 (geekbang.org)
3.4 HTTPS ECDHE 握手解析 | 小林coding (xiaolincoding.com)