Https 及抓包

Https 相关概念

什么是SSL/TLS协议？

加密相关的概念

对称加密

非对称加密

散列函数Hash（摘要算法）

数字签名

TLS握手过程

Client Hello

Server Hello

Certificate(Server)

Server Key Exchange

Certificate Request

Server Hello Done

Certificate(Client)

Client Key Exchange

Certification Verity

Change Cipher Spec(Client)

Encrypted Handshake Message(Client)

Change Cipher Spec(Server)

Encrypted Handshake Message(Server)

Application Data

证书

RSA身份验证的隐患

身份验证CA和证书

使用Charles 进行Https 抓包

安装Charles

工具导航栏

通过 Charles 进行移动端抓包

Https 抓包

Charles 功能

Breakpoints 功能

Map Local 功能

Rewrite 功能

Block List

---

Https 相关概念

HTTPS：超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，缩写：HTTPS，常称为HTTP over TLS，HTTP over SSL或HTTP Secure）是一种通过计算机网络进行安全通信的传输协议。

Https 超文本传输安全协议，是一种通过计算机网络进行安全通信的传输协议。主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。由网景公司（Netscape）在1994年首次提出，随后扩展到互联网上。

TLS/SSL 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。

可以看到HTTPS比HTTP多了一层TLS/SSL协议，TLS/SSL 就是进行加密操作的。

什么是SSL/TLS协议？

SSL (Secure Sockets Layer) “安全套接层”协议，TLS (Transport Layer Security) “安全传输层”协议，都属于是加密协议，在其网络数据传输中起到保护隐私和数据的完整性。

SSL和TLS的关系就像win7P和win10的关系，升级后改了个名字而已。下面这张表格列出了它们的历史：

协议	创建时间	创建者	RFC	注释
SSL1.0	n/a	Netscape	n/a	由于有很多安全问题，所以网景公司没有将它公之于众
SSL2.0	1995	Netscape	n/a	这是第一个被公众所了解的SSL版本
SSL3.0	1996	Netscape	rfc6101	由于2.0还是被发现有很多安全问题，Netscape于是设计了3.0，并且IETF将它整理成RFC发布了出来
TLS1.0	1999	IETF	rfc2246	基于SSL 3.0，修改不大，在某些场合也被称之为SSL 3.1，改名主要是为了和Netscape撇清关系，表示一个新时代的来临。类似于饭店换老板了，然后改了个名字，厨师还是原来的
TLS1.1	2006	IETF	rfc4346
TLS1.2	2008	IETF	rfc5246
TLS1.3	TBD	IETF	TBD	还在开发过程中，draft

加密相关的概念

对称加密

加密和解密都用同一个密钥，所以叫对称加密。常见的算法有AES、3DES。

相比而言，加密速度较快，一般加密较长的传输内容；
优点：就是快
缺点：服务器和 N 个客户端通信，需要维持 N 个密钥记录（因为客户端之间的密钥不同才安全）

非对称加密

密钥成对出现，一般称为公钥(公开)和私钥(保密)，公钥加密的信息只能私钥解开，反之亦然。常见的算法有RSA、DSA、ECC。

速度上较差，一般加密较短的内容（例如：对称加密的密钥，内容的摘要）；
优点：安全（用公钥与私钥），可以1对多的加密（N 个客户端共用一个公钥，私钥掌握在服务端，所有是安全的）
缺点：速度上较差（相比对称加密效率低些）

散列函数Hash（摘要算法）

该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定，针对数据的任何修改都会改变散列函数的结果，常见的有 MD5、SHA1、SHA256。

用于数字签名；
用于防止信息篡改并验证数据的完整性;

数字签名

数字签名就是“非对称加密+摘要算法”，其目的不是为了加密，而是用来防止他人篡改数据。

比如A要给B发送数据，A先用摘hash算法得到数据的摘要（指纹），然后用A的私钥加密摘要，得到A的签名，
B收到A的数据与A的签名，用同样的算法计算收到数据的摘要（指纹），然后用A公开的公钥解密签名得到一个摘要，
比较两个摘要，相同则数据没有被篡改，否则说明有问题。

TLS握手过程

Https 的安全机制是建立在SSL/TLS 之上的，SSL/TLS 握手是为了在不安全的通信过程里，安全地协商出一份对称加密的秘钥。

加密过程

可以简单理解为

客户端A  |   ------- Hello ------------------------->  |    服务器B
         |                                            |
         | <--- Hello -----                           |
         |          证书，公钥b，随机数b ----------     |    (私钥就在B 这边)
         |                                            |
         | --- 生成对称密钥的关键参数pre_master_secret  |
         |   （经过公钥b 加密了），随机数a -------->    |
         |                                            |
         | ----------使用对称密钥加密的数据-------->    |
         |                                            |
         | <---------使用对称密钥加密的数据---------    |

注意：
pre_master_secret  可以理解为对称密钥，因为它是关键参数拿到它就可以计算出对称密钥了，
它也是用公钥b 加密后才传输的；所有可以看出非对称加密用于加密对称密钥；
而数据的加密用的是对称密钥，但必须要安全的送到对面才行，所以用公钥加密；

RFC里面给出对称密钥的的计算方法：
master_secret = PRF(pre_master_secret, "master secret",
                          ClientHello.random + ServerHello.random)
                          [0..47];

通过 pre_master_secret , 随机数a , 随机数b 就可以算出

完成上图的加密过程就可以进行数据的加密传输了（Application Data）。

通过Wireshark 抓包，让我们从理论到实践，可以更好地理解Https 。

Client Hello

握手第一步是客户端发送Client Hello 协议请求，里面比较重要的是Cipher Suites ，这是客户端所支持一系列的加密套件，服务端收到后悔从中选一个作为加密算法。

然后，还有SSL/TSL Version  ，以及一个客户端生成的随机数 Random 。

Server Hello

告知客户端后续协议要使用的TLS版本（在这一步确定了下来，这个版本主要与客户端与服务端支持的最高版本有关）；

会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，

如下图确定的为TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xc030) 

Certificate(Server)

这一步是服务端将自己的证书发给客户端，让客户端验证自己的身份。

Server Key Exchange

如果是DH算法，这里发送服务器使用的DH参数。RSA算法不需要这一步。

Certificate Request

是服务端要求客户端上报证书（这是一个可选项，对于安全性要求高的场景会用到，比如我这次抓包就没有）。

Server Hello Done

作为结束信息，告知客户端Server Hello 过程结束。

Certificate(Client)

可选项，对应服务端的Certificate Request 请求，也就是服务端发送了Certificate Request，客户端才会发送自己的证书信息。

Client Key Exchange

发送公钥加密的对称密钥关键参数，但如果是DH 算法则发送客户端的公钥。关于DH 算法就是双方都产生一对非对称密钥，然后将公钥发送给对方，这里就是客户端将自己的公钥发送给服务端，服务端将自己的公钥发送给客户端，都保留自己的私钥，DH 算法就是根据自己私钥和对方私钥算出一个密钥，而且双方算出的相同，这样就可以使用对称加密算法加密数据了。

Certification Verity

对服务端发的证书进信息进行确认操作。

Change Cipher Spec(Client)

这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了，是一条事件消息。

Encrypted Handshake Message(Client)

这一步对应的是 Client Finish 消息，客户端将前面的握手消息生成摘要再用协商好的秘钥加密，这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密，能解出来说明前面协商出来的秘钥是一致的。

Change Cipher Spec(Server)

这一步是服务端通知客户端后面再发送的消息都会使用协商出来的加密，也是一条事件消息。

Encrypted Handshake Message(Server)

这一步对应的是 Server Finish 消息，服务端也会将握手过程的消息生成摘要再用秘钥加密，这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密，能解出来说明协商的秘钥是一致的。

Application Data

加密的数据，到这里，双方已安全地协商出了同一份秘钥，应用层数据都会用这个秘钥加密后再进行传输。

证书

通过服务端的公钥加密对称密钥安全的把对称密钥发送给对方，因为私钥这有服务端有，而之后就可以用对称密钥加密数据进行安全的传输了。

RSA身份验证的隐患

看似安全，但是如果客户端拿到的公钥不是服务端的，而是中间人的，中间人将自己的公钥发送给客户端，客户端用该公钥加密的对称密钥，就会被中间人拿到，所以必须要确认对方的身份，

而且也可能出现服务器不承认是自己发出的数据，即信息抵赖，

所以就引入了证书机制。

客户端C和服务器S进行通信，中间节点M截获了二者的通信;
节点M自己计算产生一对公钥pub_M和私钥pri_M;
C向S请求公钥时，M把自己的公钥pub_M发给了C;
C使用公钥 pub_M加密的数据能够被M解密，因为M掌握对应的私钥pri_M，
而 C无法根据公钥信息判断服务器的身份，从而 C和 * M之间建立了"可信"加密连接;
中间节点 M和服务器S之间再建立合法的连接，因此 C和 S之间通信被M完全掌握，
M可以进行信息的窃听、篡改等操作。

另外，服务器也可以对自己的发出的信息进行否认，不承认相关信息是自己发出。

因此该方案下至少存在两类问题：中间人攻击和信息抵赖。

身份验证CA和证书

解决上述身份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构CA(如沃通CA)。CA 负责核实公钥的拥有者的信息，并颁发认证"证书"，同时能够为使用者提供证书验证服务。

在TLS握手的过程中，浏览器得到了网站的证书；
打开证书，查看是哪个CA签名的这个证书；
在自己信任的CA库中，找相应CA的证书；
用CA证书里面的公钥解密网站证书上的签名，取出网站证书的摘要（指纹），然后用同样的算法（比如sha256）
算出出网站证书的校验码，如果校验码和签名中的校验码对的上，说明这个证书是合法的，且没被人篡改过；
读出里面的CN，对于网站的证书，里面一般包含的是域名；
检查里面的域名和自己访问网站的域名对不对的上，对的上的话，就说明这个证书确实是颁发给这个网站的；

如果浏览器发现证书有问题，一般是证书里面的签名者不是浏览器认为值得信任的CA，浏览器就会给出警告页面，这时候需要谨慎，有可能证书被掉包了。如访问A网站，由于A的证书是自己签的名，并且浏览器不认为A是受信的CA，所以就会给警告，但是一旦你把A的根证书安装到了你的浏览器中，那么下次就不会警告了，因为你配置了浏览器让它相信A是一个受信的CA。

使用Charles 进行Https 抓包

安装Charles

打开浏览器访问 Charles 官网 ，下载相应系统的 Charles 安装包，然后安装即可;

Charles 主界面

工具导航栏

Charles 顶部为菜单导航栏，菜单导航栏下面为工具导航栏。工具导航栏中提供了几种常用工具：

通过 Charles 进行移动端抓包

手机抓包的原理，和 PC 类似，手机通过把网络委托给 Charles 进行代理与服务端进行对话。具体步骤如下：

1. 使手机和电脑在一个局域网内，不一定非要是一个 IP 段，只要是在同一个路由器下即可。

2. 打开 Charles 的代理功能：通过主菜单打开 Proxy | Proxy Settings 弹窗，填入代理端口(端口默认为 8888，不用修改)，勾选 Enable transparent HTTP proxying。

3. 通过 Charles 的主菜单 Help | Local IP Address 或者通过命令行工具输入 ipconfig查看本机的 IP 地址。

4. 设置代理：打开手机端的 WIFI 代理设置，输入电脑 IP 和 Charles 的代理端口。

5.设置好之后，我们打开手机上的任意需要网络请求的程序，就可以看到 Charles 弹出手机请求连接的确认菜单（只有首次弹出），点击 Allow 即可完成设置。

完成上述步骤就可以抓取手机的包了，Http 抓包这样就可以了，

Https 抓包

Charles 默认不支持Https 抓包，如下：

要想抓取Https 需要稍微配置一下

1. 在SSL Proxying Settings 这里设置，如下就添加了指定Charles 可以抓取Https 的网址

在SSL Proxying Settings 设置，如进行api.weibo.cn:443 的设置，就可以抓取api.weibo.cn 的Https 包，

（所以进行*:443 的设置就可以抓取所有的Https 包了）

2. 安装证书，手机上安装Charles 的证书

手机在浏览器输入chls.pro/ssl 安装证书

iPhone 打开设置 -> 通用 -> 关于本机 -> 证书信任设置 -> 开启开关

经过上面的设置就可以抓取Https 的包了。

值得注意的是Android7.0 及更高版本就抓不了Https 的包了。

Charles 功能

Breakpoints 功能

Breakpoints 针对当前的网络请求设置断点，

可以修改请求的参数，这样就不用修改代码了，直接通过Charles 就可完成请求的相关修改；可以对相应进行修改；这样就很方便的完成某些网络功能的测试啦。

我们以修改响应为例来简单描述一下Breakpoints 功能的使用。

选中要设置的接口，右键点击Breakpoints ，这样在下次请求该接口的时候Charles 会帮我们断在该处。

可以进行请求的修改，点击右下角的Execute 可以继续执行请求。

可以看到多出Edit Response ，修改响应，如图修改了“一起看”为“一起康”，这样显示效果就这样啦

Map Local 功能

我们需要填写重定向的原地址信息和本地目标文件。我们可以先将某个接口的响应内容保存下来（选择对应的网络请求，右击点击 Save Response ）成为 data.json 文件。然后我们编辑里面的 status 、message、data 等信息为我们想要的目标映射文件。

这样再次触发该请求的时候就走我们修改过的data.json 文件，从而方便测试某些字段的值（因为我们可以随便改）。

例如保存到了桌面，命名为data.json

在Tool 菜单下选择Map Local...

勾选Enable Map Local 代表使用该功能，点击Add 添加映射信息。

填写信息Map From 为我们想要映射的原网络接口，Map To 为目标文件

返回的信息如图，由原来的“一起看”变为“意七康”。

Rewrite 功能

Rewrite 适合对某个网络请求进行正则替换，以达到修改结果的目的。使用如下。

点击去设置Rewrite ，

点击上面Location 的Add 添加我们要处理的接口

点击下面的Add 填我们的修改规则

如图，这里要修改的body ，将返回内容的“一起看”，替换为“看看吧”，这样返回的信息如下

手机App 上的效果如图

Block List

Charles 黑名单

阻止对匹配host的请求；可以直接把请求丢掉，也可以直接返回403状态码；

当Charles收到与黑名单相匹配的请求时，Charles 会阻止该请求。

白名单

当Charles 收到与白名单不匹配的请求时，Charles会阻止该请求。

就是开启百名到后Charles 只允许白名单的host 进行请求。同样可以选择Charles是否会简单地关闭浏览器的连接，或者向浏览器返回错误页面（具有403 响应）。

如果黑名单，白名单都开启呢？就是黑名单上与白名单上出现交集的部分host 会Charles怎样处理呢？

会按照黑名单的规定来。

例如开启黑名单，并设置403 响应

效果如下