HTTPS协议详解

HTTPS协议详解

从事移动互联网软件开发的小伙伴肯定了解：自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 协议详解
https://blog.csdn.net/xiaxl/article/details/104541274

二、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握手过程
https://blog.csdn.net/hherima/article/details/52469674

========== THE END ==========