前言
在了解 HTTPS 之前先了解一下什么是 HTTP ,HTTP 就是我们平时浏览网页时候使用的一种协议。但是HTTP 协议传输的数据都是未加密的,也就是明文的,因此使用 HTTP 协议传输隐私信息就显得非常不安全。为了保证这些隐私数据能安全的传输,网景公司设计了SSL( Secure Sockets Layer )协议用于对 HTTP 协议传输的数据进行加密,从而就诞生了 HTTPS 。
SSL 目前的版本是 3.0,被 IETF( Internet Engineering Task Force )定义在 RFC 6101 中,之后 IETF 对 SSL 3.0 进行了升级,于是出现了TLS( Transport Layer Security ) 1.0 ,定义在 RFC 2246 。实际上我们现在的 HTTPS 都是用的 TLS 协议,但是由于 SSL 出现的时间比较早,并且依旧被现在浏览器所支持,因此 SSL 依然是 HTTPS 的代名词,但无论是 TLS 还是 SSL 其目标都是提供加密服务,SSL 最后一个版本是 3.0 ,今后TLS 将会继承 SSL 优良血统继续为我们进行加密服务。目前TLS的版本是 1.4 。
HTTPS 在传输数据之前需要客户端(浏览器)与服务端(网站)之间进行一次握手,在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL 协议不仅仅是一套加密传输的协议,更是一件经过艺术家精心设计的艺术品, TLS/SSL 中使用了非对称加密,对称加密以及 HASH 算法。
TCP、SSL/TLS、HTTP(S) 的关系
网络协议套件
上图截自维基百科,对协议进行了明确的划分。
- TCP
传输控制协议,属于传输层协议,提供可靠数据传输。它为 HTTP 等应用层协议提供服务。 - SSL/TLS
安全传输层协议,用于在两个通信应用程序之间提供保密性和数据完整性。位于某个可靠的传输协议(例如 TCP)上面,属于应用层协议。 - HTTP
超文本传输协议,属于应用层协议。依赖于TCP协议。
- HTTPS
在HTTP和TCP中间加入了 SSL/TLS ,保证数据传输的安全性
HTTPS抓包演示
HTTPS握手
我们使用 wireshark 对一个 HTTPS 请求进行抓包,如下所示。
HTTPS 抓包
上图是一个完整的 HTTPS 请求抓包。但是看起来比较混乱,可以将其内容总结为下图。
请求流程
这里忽略了三次握手和四次挥手,相信会看这篇文档的同学应该都有这些基础网络知识。好的,下面我们通过抓包来一步一步分析
第一步: Client Hello
先看一下抓出来包的内容,我们直接看到 SSL 层
这一步干啥了呢?
- TLS 的版本
- 随机数:这个是用来生成最后加密密钥的影响因子之一,包含两部分:时间戳( 4-Bytes )和随机数( 28-Bytes )
- session-id:用来表明一次会话,第一次建立没有。如果以前建立过,可以直接带过去。
- 加密算法套装列表:客户端支持的加密-签名算法的列表,让服务器去选择。
- 压缩算法:客户端支持的压缩算法,也让服务器去选择。
扩展字段:比如密码交换算法的参数、请求主机的名字等等。
这里要注意一个随机数,很重要。我们先记为 Random1 。
第二步: Server Hello
- 据客户端支持的 SSL/TLS 协议版本,和自己的比较确定最终使用的 SSL/TLS 协议版本
- 确定加密套件,压缩算法。
- 产生了一个随机数 Random2 ,至此客户端和服务端都拥有了两个随机数( Random1 + Random2 ),这两个随机数会在后续生成对称秘钥时用到。
第三步: Server => Client
这次传输包含三部分内容
- Certificate
- Server Key Exchange
- ServerHello Done
这里是一个优化,将三个部分一起发送,我们一个个分析
Certificate
这里主要就是把证书发送给 Client 。图中可以看到我的证书和证书发放机构。客户端拿到证书后就可以进行验证,同时获取到公钥,用于后面 Random3 的加密。
证书一般采用 X.509 标准。
Server Key Exchange
这个消息是用来发送密钥交换算法相关参数和数据的。这里要提前提一下,就是根据密钥交换算法的不同,传递的参数也是不同的。
常用的密钥交换算法:RSA、DH( Diffie-Hellman )、ECDH( Ellipticcurve Diffie–Hellman )。
这里看到使用的 ECDH 。
Server Hello Done
这个就是 Server 来表示自己说完了。类似电影里别人拿对讲机说完话最后会有一个“完毕!”。
第四步: Client => Server
这次传输也包含三部分内容,也是做了一个优化
- Client Key Exchange
- Change Cipher Spec
- Encrypted Handshake Message
Client Key Exchange
这个也是交换秘钥参数。
这里客户端会再生成一个随机数 Random3 。然后使用服务端传来的公钥进行加密得到密文 PreMaster Key 。服务端收到这个值后,使用私钥进行解密,得到 Random3 。这样客户端和服务端就都拥有了 Random1 、 Random2 和 Random3 。这样两边的秘钥就协商好了。后面数据传输就可以用协商好的秘钥进行加密和解密。
Change Cipher Spec
编码改变通知。这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了,是一条事件消息。
Encrypted Handshake Message
这一步对应的是 Client Finish 消息,客户端将前面的握手消息生成摘要再用协商好的秘钥加密,这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密,能解出来说明前面协商出来的秘钥是一致的。
第五步 Server => Client
包括三部分
- New Session Ticket
- Change Cipher Spec
- Encrypted Handshake Message
New Session Ticket
包含了一个加密通信所需要的信息,这些数据采用一个只有服务器知道的密钥进行加密。目标是消除服务器需要维护每个客户端的会话状态缓存的要求。
Change Cipher Spec
编码改变通知,这一步是服务端通知客户端后面再发送的消息都会使用加密,也是一条事件消息。
Encrypted Handshake Message
这一步对应的是 Server Finish 消息,服务端也会将握手过程的消息生成摘要再用秘钥加密,这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密,能解出来说明协商的秘钥是一致的。
到这里双方SSL/TLS握手完成。
HTTPS 数据传输
接下来就真正的到了数据请求的阶段。TLS 的 Content-Type 为 Application Data。传输的内容也是加密的。
拓展内容
证书
证书种类
证书格式
一般来说,主流的 Web 服务软件,通常都基于 OpenSSL 和 Java 两种基础密码库。
- Tomcat、Weblogic、JBoss 等 Web 服务软件,一般使用 Java 提供的密码库。通过 Java Development Kit (JDK)工具包中的 Keytool 工具,生成 Java Keystore(JKS)格式的证书文件。
- Apache、Nginx 等 Web 服务软件,一般使用 OpenSSL 工具提供的密码库,生成 PEM、KEY、CRT 等格式的证书文件。
- IBM 的 Web 服务产品,如 Websphere、IBM Http Server(IHS)等,一般使用 IBM 产品自带的 iKeyman 工具,生成 KDB 格式的证书文件。
微软 Windows Server 中的 Internet Information Services(IIS)服务,使用 Windows 自带的证书库生成 PFX 格式的证书文件。
证书类型
您可以使用以下方法简单区分带有后缀扩展名的证书文件:
.DER 或 .CER 文件: 这样的证书文件是二进制格式,只含有证书信息,不包含私钥。
- .CRT 文件: 这样的证书文件可以是二进制格式,也可以是文本格式,一般均为文本格式,功能与 .DER 及 *.CER 证书文件相同。
- .PEM 文件: 这样的证书文件一般是文本格式,可以存放证书或私钥,或者两者都包含。 .PEM 文件如果只包含私钥,一般用 *.KEY 文件代替。
- .PFX 或 .P12 文件: 这样的证书文件是二进制格式,同时包含证书和私钥,且一般有密码保护。
您也可以使用记事本直接打开证书文件。如果显示的是规则的数字字母,例如:
—–BEGIN CERTIFICATE—–
MIIE5zCCA8+gAwIBAgIQN+whYc2BgzAogau0dc3PtzANBgkqh......
—–END CERTIFICATE—–
那么,该证书文件是文本格式的。
如果存在——BEGIN CERTIFICATE——,则说明这是一个证书文件。
如果存在—–BEGIN RSA PRIVATE KEY—–,则说明这是一个私钥文件。
更多内容参考主流数字证书都有哪些格式?