从事移动互联网软件开发的小伙伴肯定了解: 自 Android 9.0 开始, 应用程序的网络请求默认使用 https; 基本是同期苹果 iOS 在应用网络请求方面, 也强制使用 https 禁止 http.
这一期间如果你去面试, 不了解 Https 的握手过程, 都不好意思讲工资.
本人一个普通程序员, 项目期间工期紧张, 并未抽出时间详细了解 Https 网络请求过程中 TLS 握手过程, 因此这件事一直在我的待办记录中...
这篇文章以 Wireshark 抓包, 详细了解 Https 请求中 TLS 的握手过程 与 客户端证书校验过程.
HTTPS 简介
SSL/TLS 握手过程
客户端 证书校验
一, HTTPS 简介
HTTPS (Secure Hypertext Transfer Protocol)安全超文本传输协议, 是一种通过计算机网络进行安全通信的传输协议.
HTTPS 利用 SSL/TLS 来加密数据包, 经由 HTTP 进行通信.
其设计的主要目的是, 提供对网站服务器的身份认证, 保护交换数据的隐私与完整性.
- TLS/SSL
- SSL(Secure Socket Layer)
1994 年由 浏览器开发商 Netscape 公司 率先倡导研发, 为数据通讯提供安全支持, 开发了最初的几个版本 SSL 1.0,SSL 2.0,SSL 3.0.
TLS(Transport LayerSecurity)
前身为 SSL,1999 年从 3.1 开始被 IETF(Internet Engineering Task Force,Internet 工程任务组)标准化并改名, 发展至今已经有 TLS 1.0,TLS 1.1,TLS 1.2 三个版本.
SSL3.0 和 TLS1.0 由于存在安全漏洞, 已经很少被使用到;
TLS 1.3 改动会比较大, 目前还在草案阶段, 目前使用最广泛的是 TLS 1.1,TLS 1.2;
TLS/SSL 是介于 TCP 和 HTTP 之间的一层安全协议.
Http
HTTP(HyperText Transfer Protocol)超文本传输协议.
HTTP 是一个客户端 (用户) 和服务端之间请求和应答的标准, 其最初的设计目的是为了提供一种发布和接收 html 页面的方法.
Http 协议不是本文重点, 感兴趣的同学可参考文章:
HTTP 协议详解
二, SSL/TLS 握手过程
SSL/TLS 握手过程用一句话总结就是: 用非对称加密的手段传递密钥, 然后用密钥进行对称加密传递数据.
以下为 SSL/TLS 握手过程的时序图:
这里以客户端向百度主页发起 Https 请求为例, 用 Wireshark 抓包对 SSL/TLS 握手的各个环节进行介绍, Wireshark 抓包示意图如下图所示:
2.1,Client Hello ( Client-->Server )
握手第一步是客户端向服务端发送 Client Hello 消息, 消息中包含客户端的 TSL 版本信息, 秘钥随机数, 加密套件候选列表, 压缩算法候选列表, 扩展字段等信息, 相关信息通过 Wireshark 抓包如下:
Version : 支持的最高 TSL 协议版本, 从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
Random: 随机数 random_C 用于后续的密钥协商;
Session ID: 有或者无, 有则客户端传上一次 session 的 id 可以恢复 session;
Cipher Suite: 客户端支持的密码算法列表, 供服务器选择;
Compression Methods: 客户端支持的压缩算法列表, 用于后续的信息压缩传输;
extensions: 扩展字段;
2.2,Server Hello ( Server-->Client )
服务端向客户端发送 Server Hello 消息: 包括服务端选择使用的 TSL 协议版本, 选择的加密套件, 选择的压缩算法, 服务端生成的随机数等, 相关信息通过 Wireshark 抓包如下:
Version: 服务器选择的版本;
Random: 随机数 random_S 用于后续的密钥协商;
Session ID: 有或者无, 有则客户端传上一次 session 的 id 可以恢复 session;
Cipher Suite: 服务端选择的密钥算法;
Compression Methods: 服务端选择的压缩算法;
到此客户端和服务端都拥有了两个随机数(random_C+ random_S), 这两个随机数会在后续生成对称秘钥时用到.
2.3,Certificate ( Server-->Client )
服务端下发服务端的公钥证书给客户端, 相关信息通过 Wireshark 抓包如下:
Certificate 服务端的公钥证书;
2.4,Server Key Exchange ( Server-->Client )
该消息的目的是携带密钥交换的额外数据, 该消息内容对于不同的协商算法套件会存在差异:
对于使用 DHE/ECDHE 非对称密钥协商算法的 SSL 握手, 服务器发送其使用的 DH 参数;
RSA 算法不会继续该握手流程(DH,ECDH 也不会发送 server key exchange).
2.5,Server Hello Done ( Server-->Client )
通知客户端, 服务端已经将所有预计的握手消息发送完毕.
2.5, 证书校验 (客户端进行证书校验)
客户端拿到服务端的公钥证书后, 需对该证书的合法性进行校验, 校验内容如下:
证书链的可信性;
证书是否吊销;
证书有效期;
证书域名校验, 核查证书域名是否与当前的访问域名匹配;
注:
证书的详细校验过程将在下文进行详细介绍
- 2.6,Client Key Exchange,Change Cipher Spec Protocol,Encrypted Handshake Message ( Client-->Server )
- Client Key Exchange
证书合法性验证通过之后, 客户端产生随机数字 Pre-master, 计算生成秘钥 enc_key(
enc_key=Fuc(random_C, random_S, Pre-Master)
, 将 Pre-master 与 enc_key 用
证书公钥加密(非对称加密算法)
发送给服务端;
Change Cipher Spec Protocol
客户端通知服务端后续的通信都采用
协商的通信密钥
和加密算法进行加密通信;
Encrypted Handshake Message
客户端将之前
所有的握手数据(包括接受, 发送)
生成摘要, 然后用
协商好的秘钥 enc_key 加密(对称加密算法)
, 发送给对应的服务端;
服务端收到消息后, 会用秘钥 enc_key 解密
客户端的摘要信息
, 然后用与客户端相同的算法生成
服务端摘要信息
, 最后对比两个摘要信息相同, 则验证通过;
2.7,Change Cipher Spec Protocol ( Server-->Client )
服务器同样发送 Change Cipher Spec Protocol 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;
2.8,Encrypted Handshake Message ( Server-->Client )
服务端也会将握手过程的消息生成摘要再用秘钥加密, 这是服务端发出的第一条加密消息;
客户端接收后会用秘钥解密, 能解出来说明协商的秘钥是一致的.
2.9,Application Data ( Client-->Server )
到这里, 双方已安全地协商出了同一份秘钥 enc_key, 所有的应用层数据都会用这个秘钥加密后再通过 TCP 进行可靠传输.
2.10 总结
SSL/TLS 握手过程: 用非对称加密的手段传递密钥, 然后用密钥进行对称加密传递数据.
三, 证书校验
客户端验证服务端下发的证书, 主要包括以下几个方面:
第一, 校验证书是否是
受信任的 CA 根证书颁发机构
颁发;
第二, 校验证书是否在上级证书的吊销列表;
第三, 校验证书是否过期;
第四, 校验证书域名是否一致.
3.1, 校验证书是否是由
受信任的 CA 根证书颁发机构
颁发
为了确保客户端获取到的服务端公钥不被篡改, 需引入权威的第三方 CA 机构.
CA 机构负责核实公钥拥有者信息, 颁发 "证书(对服务端公钥进行签名)", 同时为使用者提供证书验证服务.
CA 机构颁发证书的基本原理为:
服务端生成一对服务端公钥, 服务端私钥;
服务端将自己的服务端公钥提供给 CA 机构;
CA 机构核实服务端公钥拥有者信息(核实申请者提供信息的真实性, 如组织是否存在, 企业是否合法, 是否拥有域名的所有权等);
CA 机构计算
服务端公钥的摘要信息
, 利用 CA 机构的私钥 (CA 机构有一对公钥, 私钥) 进行加密,
加密后的服务端公钥即 CA 机构颁发的 "证书"
;
客户端验证服务端公钥的基本原理为:
Https 网络请求过程中, 客户端获取到服务端的公钥;
客户端用存储在本地的 CA 机构的公钥, 对 服务端公钥进行解密, 获取到
服务端公钥的摘要信息 A
;
客户端计算服务端公钥的摘要信息 B;
对比摘要信息 A 与 B, 相同则证书验证通过;
3.2, 校验证书是否在上级证书的吊销列表
CA 机构能够签发证书, 同样也存在机制宣布以往签发的证书无效. 使用者私钥丢失, 使用者申请让证书无效等情况, CA 机构需要废弃该证书.
主要存在两类机制: CRL 与 OCSP.
CRL(Certificate Revocation List)
证书吊销列表是一个单独的文件, 该文件包含了 CA 机构 已经吊销的证书序列号与吊销日期;
证书中一般会包含一个 URL 地址
CRL Distribution Point
, 通知使用者去哪里下载对应的 CRL 以校验证书是否吊销.
该吊销方式的优点是不需要频繁更新, 但是不能及时吊销证书, 因为 CRL 更新时间一般是几天, 这期间可能已经造成了极大损失.
OCSP(Online Certificate Status Protocol)
证书状态在线查询协议, 一个实时查询证书是否吊销的方式.
请求者发送证书的信息并请求查询, 服务器返回正常, 吊销或未知中的任何一个状态.
证书中一般也会包含一个 OCSP 的 URL 地址, 要求查询服务器具有良好的性能.
部分 CA 或大部分的自签 CA (根证书)都是未提供 CRL 或 OCSP 地址的, 对于吊销证书会是一件非常麻烦的事情.
3.3, 校验证书是否过期
校验证书的有效期是否已经过期
3.4, 校验证书域名是否一致
校验证书域名是否一致: 核查证书域名是否与当前的访问域名匹配.
这里核验的是我们请求的域名 www.baidu.com 是否与证书文件中 DNS 标签下所列的域名相匹配;
注:
具体的证书文件举例, 请查看第四节 "四, 证书举例" .
一种错误的写法:
Android 软件开发中, 我们经常会遇到以下代码, 用来忽略证书的域名验证, 其实这是一种不安全的写法:
- // 对于自签名证书, 用以下代码来忽略证书的域名验证
- HostnameVerifier hostnameVerifier = new HostnameVerifier() {
- @Override
- public boolean verify(String urlHostName, SSLSession session) {
- // 忽略证书的域名验证
- return true;
- }
- };
四, 证书举例
这里以百度的 Https 证书举例:
- Certificate:
- Data:
- Version: 3 (0x2)
- Serial Number:
- 72:58:78:36:6e:9f:56:e8:1d:41:88:48
- Signature Algorithm: sha256WithRSAEncryption
- Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
- Validity
- Not Before: Apr 2 07:04:58 2020 GMT
- Not After : Jul 26 05:31:02 2021 GMT
- Subject: C=CN, ST=beijing, L=beijing, OU=service operation department, O=Beijing Baidu Netcom Science Technology Co., Ltd, CN=baidu.com
- Subject Public Key Info:
- Public Key Algorithm: rsaEncryption
- Public-Key: (2048 bit)
- Modulus:
- 00:c1:a9:b0:ae:47:1a:d2:57:eb:1d:15:1f:6e:5c:
- b2:e4:f8:0b:20:db:ea:00:df:29:ff:a4:6b:89:26:
- 4b:9f:23:2f:ec:57:b0:8a:b8:46:40:2a:7e:bc:dc:
- 5a:45:97:4f:ad:41:0e:bc:20:86:4b:0c:5d:55:21:
- 47:e2:31:3c:57:a7:ec:99:47:eb:47:0d:72:d7:c8:
- 16:54:75:ef:d3:45:11:0f:4b:ce:60:7a:46:5c:28:
- 74:ae:8e:1b:be:d8:70:66:7b:a8:93:49:28:d2:a3:
- 76:94:55:de:7c:27:f2:0f:f7:98:0c:ad:86:da:c6:
- ae:fd:9f:f0:d9:81:32:9a:97:e3:21:ee:04:92:96:
- e4:78:11:e5:c4:10:0e:10:31:7a:4a:97:a0:eb:c7:
- 9b:c4:da:89:37:a9:c3:37:d7:56:b1:7f:52:c7:d9:
- 26:0a:d6:af:38:16:b1:6d:fb:73:79:b1:68:79:03:
- 90:eb:88:7b:8c:48:91:98:51:a5:07:94:86:a5:78:
- 46:79:8f:58:9b:e9:35:59:a7:f1:7b:57:31:0a:90:
- cf:24:ce:0d:24:e7:92:b2:6a:e9:e6:96:37:0a:b8:
- 7c:87:2f:74:d2:5c:e8:4b:0a:5f:66:18:a7:41:86:
- cf:26:a6:08:8e:a5:49:17:92:53:b3:91:a5:cf:53:
- b0:31
- Exponent: 65537 (0x10001)
- X509v3 extensions:
- X509v3 Key Usage: critical
- Digital Signature, Key Encipherment
- Authority Information Access:
- CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
- OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2
- X509v3 Certificate Policies:
- Policy: 1.3.6.1.4.1.4146.1.20
- CPS: https://www.globalsign.com/repository/
- Policy: 2.23.140.1.2.2
- X509v3 Basic Constraints:
- CA:FALSE
- X509v3 CRL Distribution Points:
- Full Name:
- URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl
- X509v3 Subject Alternative Name:
- DNS:baidu.com, DNS:baifubao.com, DNS:www.baidu.cn, DNS:www.baidu.com.cn, DNS:mct.y.nuomi.com, DNS:apollo.auto, DNS:dwz.cn, DNS:*.baidu.com, DNS:*.baifubao.com, DNS:*.baidustatic.com, DNS:*.bdstatic.com, DNS:*.bdimg.com, DNS:*.hao123.com, DNS:*.nuomi.com, DNS:*.chuanke.com, DNS:*.trustgo.com, DNS:*.bce.baidu.com, DNS:*.eyun.baidu.com, DNS:*.map.baidu.com, DNS:*.mbd.baidu.com, DNS:*.fanyi.baidu.com, DNS:*.baidubce.com, DNS:*.mipcdn.com, DNS:*.news.baidu.com, DNS:*.baidupcs.com, DNS:*.aipage.com, DNS:*.aipage.cn, DNS:*.bcehost.com, DNS:*.safe.baidu.com, DNS:*.im.baidu.com, DNS:*.baiducontent.com, DNS:*.dlnel.com, DNS:*.dlnel.org, DNS:*.dueros.baidu.com, DNS:*.su.baidu.com, DNS:*.91.com, DNS:*.hao123.baidu.com, DNS:*.apollo.auto, DNS:*.xueshu.baidu.com, DNS:*.bj.baidubce.com, DNS:*.gz.baidubce.com, DNS:*.smartapps.cn, DNS:*.bdtjrcv.com, DNS:*.hao222.com, DNS:*.haokan.com, DNS:*.pae.baidu.com, DNS:*.vd.bdstatic.com, DNS:click.hm.baidu.com, DNS:log.hm.baidu.com, DNS:cm.pos.baidu.com, DNS:wn.pos.baidu.com, DNS:update.pan.baidu.com
- X509v3 Extended Key Usage:
- TLS web Server Authentication, TLS Web Client Authentication
- X509v3 Authority Key Identifier:
- keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
- X509v3 Subject Key Identifier:
- ......
五, 参考
- TSL:
- https://tools.ietf.org/html/rfc5246
SSL/TSL 原理:
https://www.cnblogs.com/chenjingquan/p/10531305.html
TLS/SSL 握手过程
========== THE END ==========
来源: https://www.cnblogs.com/xiaxveliang/p/13183175.html