HTTPS 以及 Charles 抓包

一直对认证方面云里雾里，感觉看过多少篇文章理解也不是很透彻，偶然工作中遇到了认证问题，再去查再去看，好像一下子明白了很多，果然学习知识是要循序渐进。这里总结一下HTTPS以及用Charles抓HTTPS包要如何配置。

这里先po出我觉得比较好并且引用的两篇文章链接

关于HTTPS原理以及iOS Challenge

关于HTTPS原理以及Charles配置

我引用了这两篇文章里面的一些内容，按照自己的理解串了一遍，做一个总结。

HTTPS

一、HTTP

HTTP是一种常用的网络传输协议，它是基于TCP的一种应用层协议:

HTTP安全性问题：

传输数据时是明文的，任何人通过一个简单的抓包工具，就可以截获到所有传输数据
传输数据时无法保证数据的完整，在截获到明文数据后，很容易就可以将其篡改，这也是一些网页总是被植入恶意广告的原因
传输数据时无法保证真实性，这也是最恐怖的一点。误入了域名欺骗的钓鱼网站，极容易对用户带来财产损失

二、HTTPS

要理解HTTPS协议，首先需要明白什么是SSL/TLS。SSL全称“Secure Sockets Layer”，意思为安全套接层。其实由网景公司为了解决HTTP传输协议在安全方面的缺陷而设计的。后来被标准化，更名为TLS，全称“Transport Layer Security”，意思为传输层安全协议。

HTTPS就是将HTTP协议与TLS协议组合起来，在不改变HTTP协议原设计的基础上，为其添加安全性校验并对传输的数据进行加密。

三、证书与加密

HTTPS主要是为了解决3个问题：数据加密、数据完整、数据真实。

数据完整与真实性靠一种关键技术：数字证书。

数据加密在发送数据前依赖SSL层对数据进行加密

数字证书

通过一个小例子可以很容易的理解证书的作用，这个例子的来源是<编程随想>的作者，我这里暂且借用一下：A公司的a到B公司办事，为了证明a确实是A公司的职员而不是商业间谍，A公司会为a提供一个带有公章的证明，当B公司看到这个证明时，就可以信任办事员a。对比网络传输，这个证明就是证书，证书可以保证这个网站的真实性。我们继续往后分析，当B公司与越来越多的公司进行商业合作时，就又有新的问题出现了，比如C公司的c来B公司办事，就需要拿C公司带公章的证明，D公司的d来B公司办事就需要拿D公司带公章的证明...这样一来，B公司要存放好多公司的公章和证明的模板，才能够完成校验。这样未免也太麻烦了，对应到网络传输中，客户端就是B公司，各个网站都有自己的证书文件，这样客户端需要安装信任大量的证书，为了解决这样的问题，就有了第三方CA机构。第三方CA机构是由大家公认信任的机构，例如R公司为第三方信任机构，其业务是为其他公司提供公章证明，这样一来，B公司只要保有这个R公司的公章证明副本，其他A，C，D公司的办事员也只需要从R公司申请到一个公章证明就可以到B公司来交流业务了。

CA的全称是“Certificate Authority”，意为证书授权中心。大部分CA机构颁发的证书都是需要付费的，CA机构颁发的证书一般都是根证书，根证书也比较容易理解，首先证书是有链式信任关系的，例如Y证书是由CA机构颁发的根证书，由这个Y证书还可以创建出许多子证书，子证书可以继续创建子证书，只要根证书是受信任的，其下所有的子证书都是受信任的，如下图：

我们可以打开开源中国博客的主页：https://www.oschina.net/blog。在Chrome浏览器地址栏左边可以查看证书信息，如下：

点击证书信息，可以看到完整的证书链，如下图：

从图中可以看到，根证书是由CA机构VerSign公司颁发的。此处还可以看到当前证书是否有效以及过期时间，如果证书无效则说明此网页信息有可能被篡改过，用户在访问时就要小心了。

除了CA机构可以签发证书外，个人其实也是可以创建证书的，当然个人创建的证书也是不被信任的，我们姑且把这类证书叫做自签名证书，如果用自签名证书搭建了HTTPS的服务，则客户端需要安装对应的证书信任，才可以进行此服务的访问。

加密

HTTPS在保证数据安全传输上使用了加密算法，基本思路是非对称加密和对称加密结合来传输数据，一言以弊之，HTTPS是通过一次非对称加密算法（如RSA算法）进行了协商密钥的生成与交换，然后在后续通信过程中就使用协商密钥进行对称加密通信，之所以要使用这两种加密方式的原因在于非对称加密计算量较大，如果一直使用非对称加密来传输数据的话，会影响效率。如图

1.HTTPS请求

这个步骤是整个通信过程中的第一步，首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，在这一步中，客户端主要向服务器提供以下信息：

支持的协议版本，比如TLS 1.0版
一个客户端生成的随机数RandomC，稍后用于生成“协商密钥”。
支持的加密方法，比如RSA公钥加密。
支持的压缩方法。

2.服务器响应

服务器收到客户端请求后，向客户端发出回应，服务器的回应一般包含以下内容：

确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
一个服务器生成的随机数RandomS，稍后用于生成“协商密钥”*。
从客户端支持的加密方法中选择一个作为确认要使用的加密方法，比如RSA公钥加密。
服务器证书。
这个服务器证书就是表明服务器身份的东西，其中也包含了非对称加密中需要使用的公钥。

3.证书校验、生成密码、公钥加密

客户端收到服务器回应以后，首先验证服务器返回的证书。如果证书不是可信机构颁发，或者证书中的域名与实际域名不一致，或者证书已经过期，以浏览器为例客户端会向网页访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后生成密码、公钥加密。
生成密码的过程会先产生一个随机数Pre-master key，该随机数是整个握手阶段出现的第三个随机数，稍后会经过公钥加密发送到服务端，有了它以后，客户端和服务器就同时有了三个随机数——RandomC，RandomS，Pre-master key，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把“协商密钥”。

4.加密信息C-S

加密信息是指上面一步生成的内容，主要包括

一个随机数Pre-master key。用于给服务端生成“协商密钥”。
编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
客户端握手结束通知，表示客户端的握手阶段已经结束。这一项通常也是前面发送的所有内容的hash值，用来供服务器校验。

5.私钥解密、解密握手消息、验证Hash

服务器收到客户端公钥加密的第三个随机数Pre-master key之后，通过自身私钥解密该数值并由之前的RandomC和RandomS计算生成本次会话所用的“会话密钥”。然后，通过约定的Hash算法验证客户端发送的数据完整性。

6.加密信息S-C

主要是指

编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发生的所有内容的hash值，用来供客户端校验。

7.解密握手消息、验证Hash

客户端解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束。

8.正常加密通信

握手成功之后，所有的通信数据将由之前协商密钥及约定好的算法进行加密解密。

Charles抓取HTTPS包原理

Charles本身是一个协议代理工具，如果只是普通的HTTP请求，因为数据本身没经过再次加密，因此作为代理可以知道所有客户端发送到服务端的请求内容以及服务端返回给客户端的数据内容，这也就是抓包工具能够将数据传输内容直接展现出来的原因。对于HTTPS请求，4，6，8步骤的数据都已经经过了加密，代理如果什么都不做的话是无法获取到其中的内容的。为了实现这个过程的数据获取，Charles需要做的事情是对客户端伪装服务端，对服务端伪装客户端，具体

截获真实客户端的HTTPS请求，伪装客户端向真实服务端发送HTTPS请求
接受真实服务器响应，用Charles自己的证书伪装服务端向真实客户端发送数据内容

一般情况下HTTPS中是客户端对服务端做证书校验，当然也有一些金融机构会有用户证书作为提供给服务端做用户认证的工具，保证发出请求的的确是这部分授权用户。我们仅分析客户端对服务单做证书校验的这种。这种方法的特点是证书校验工作交由系统处理，系统只会允许可信CA签发的数字证书能够访问，私有CA签发的数字证书（比如12306以及我们上文说的Charles证书）是无法访问的。因此将Charles私有CA签发的数字证书安装到手机中并且作为受信任证书保存可以解决这个问题。