前言
大家好，我是六六。今天分享的内容是https的加密机制，大家看完后大家可以学习到一下知识点：
- https整个加密机制
- 对称加密在https的运用
- 非对称加密在https的运用
- 数字签名和数字证书
- charles抓包工具原理分析
2.1 什么是https?
安全超文本传输协议（HTTPS） 是HTTP协议的安全版本，使用 SSL /TLS 协议用于加密和身份验证。
2.2 为什么要用https?
-
http不安全：http的内容是明文传输的，明文数据会经过中间代理服务器、路由器、wifi热点、通信服务运营商等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。
-
完整性：通过加密和身份验证，HTTPS保护网站与用户浏览器之间通信的完整性。 您的用户将知道，您的Web服务器发送的数据尚未被传输中的第三方拦截和/或更改。
-
安全性：数据通过对称加密和非对称加密，保证在传输过程中及时暴露了，也很难被破解。
-
用户体验： 浏览器用户界面的最新更改导致HTTP网站被标记为 不安全 您是否要让客户的浏览器告诉他们您的网站“不安全”或在他们访问网站时向他们显示交叉锁？ 当然不是！
-
兼容性： 当前浏览器的更改使HTTP越来越不兼容。
2.3什么是对称加密？
在对称加密中，有一个秘钥，它可以对数据进行加密，同时也可以对加密的数据进行解密。在对称加密算法中，使用的密钥只有一个，发收信双方都使用这个密钥对数据进行加密和解密，这就要求解密方事先必须知道加密密钥。
那么对称加密安全吗？我们来看一个例子。
现在浏览器和服务器准备进行通信，服务器生成一个秘钥key，服务器和浏览器说我给你一个秘钥Key,你每次传输数据时用秘钥加密一下，我发你的数据也用秘钥解密一下就好了。这样就不用导致明文在传输中裸奔了。听上去很安全，但是有一个关键问题就是，如果中间人把秘钥key给劫持了呢，那这些加密的数据和明文一样了。那么，该怎么办呢？这时候就要用到非对称加密。
2.4什么是非对称加密？
在非对称加密中，有两把密钥，一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，用私钥加密的内容只有公钥能解开。但是其中算法强度复杂，性能远不如对称加密。
那么非对称加密安全吗？我们来看一个例子。
现在浏览器和服务器准备进行通信，服务器会生成一个公钥key和一个私钥key。服务器和浏览器说我给你一个公钥Key，传输数据的时候用公钥加密一下，数据到服务器中用私钥解密一下。即使中间人获取了公钥，但是私钥在服务器手里不参与通信（非常安全），他无法解密。这样一看，是不是很安全了？
仔细想一想，从浏览器到服务器非常安全，但是服务器到浏览器中公钥key是明文传输，中间人劫持key后，后续服务器传来的数据都能被中间人破解，这样一看，好像也不是很安全。那么，对称加密和非对称加密结合起来可以吗？
2.5非对称加密+对称加密？
看一下下面的例子：
- 服务器通过非对称加密生成一对公钥A、私钥A1。
- 浏览器向服务器服务器发起请求，服务器把公钥A通过明文传输到浏览器。
- 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
- 服务器拿到后用私钥A解密得到密钥X。
- 这样浏览器和服务器都拥有秘钥X，所有数据通过秘钥解密就好了。
目前，https就是采用这种加密方式。你认为这样就完美了吗？
2.6中间人如何破解非对称加密+对称加密？
看看中间人的操作：
- 服务器拥有用于非对称加密的公钥A、私钥A1。
- 浏览器向服务器请求，服务器把公钥A明文给传输浏览器。
- 中间人劫持到公钥A，把数据中的公钥A替换成自己伪造的公钥B 。
- 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法知道公钥是哪里的）加密后传给服务器。
- 中间人劫持后用私钥B解密得到密钥X，再用公钥A加密后传给服务器。
- 服务器拿到后用私钥A1解密得到密钥X。
天呐，浏览器无法确认出来公钥是否来自所请求的网站，也就是说，公钥和网站信息缺少对应关系。
2.7如何解决浏览器收到的公钥一定是服务器的公钥呢？
这个时候我们就需要一个机构，这个机构能够证明这个公钥和这个服务器是一对的。是绝对可信的。这个机构就可以向浏览器发放身份证明。它就是CA机构，它是如今互联网世界正常运作的前提，而CA机构颁发的身份证明就是数字证书。
2.8数字证书。
网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。而这里又有一个显而易见的问题，“证书本身的传输过程中，如何防止被篡改” ？即如何证明证书本身的真实性？身份证运用了一些防伪技术，而数字证书怎么防伪呢？
2.9数字签名？
我们把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫数字签名：
数字签名的制作过程：
- 首先，CA机构拥有非对称加密秘钥key和公钥key。
- CA机构对明文数据进行hash得到T。（为什么要hash,因为hash固定体积，切体积相较于明文很小，非对称加密性能不好。）
- 对hash后的值用私钥加密，得到数字签名S。
浏览器验证过程：
- 拿到证书，得到明文hash值T和数字签名S。
- 用CA机构的公钥(哪里来的，后面会讲)对数字签名解密得到明文S1。
- 用证书里指明的hash算法对明文进行hash得到T1。
- T1应当等于S1，表示证书可信。如果明文或签名被篡改，T1就不会等于S1.
假设中间人进行攻击：
- 进行证书掉包：假设有另一个网站B也拿到了CA机构认证的证书，它想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了。听上去算是没问题的，但是证书里包含了正确网址的信息，浏览器只用对比自己请求的域名和证书的域名就好了。
- 证书篡改：假设中间人篡改了证书的原文，由于他没有CA机构的私钥，它无法对签名进行数据修改。如果修改了明文，客户端进行对比发现T1不等于S1说明证书有问题。
2.10 客户端拥有的CA机构是哪里来的？
在我们的操作系统、浏览器中本身会预装一些它们信任的根证书，如果其中会有CA机构的根证书，这样就可以拿到它对应的可信公钥了。
2.11 每次进行HTTPS请求时都必须在SSL/TLS层进行握手传输密钥吗？
秘钥传输是非常耗时间的，所以服务器会为每个浏览器维护一个session ID，在TLS握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了。
3.实战分析：charles等抓包工具如何代理https?
3.1charels使用介绍
用过这些抓包工具的人应该都知道，我们在抓取http的包时，是都能够正常显示的，但是抓取https时，就会报错，这个时候我们就会去charles的官网下载一个证书，浏览器信任证书之后，https的包才能够抓取。
3.2 Charles官网对HTTPS代理的描述：
Charles作为一个中间人代理，当浏览器和服务器通信时，Charles接收服务器的证书，但动态生成一张证书发送给浏览器，也就是说Charles作为中间代理在浏览器和服务器之间通信，所以通信的数据可以被Charles拦截并解密。由于Charles更改了证书，浏览器校验不通过会给出安全警告，必须安装Charles的证书后才能进行正常访问。
3.3 原理分析：
- 客户端向服务器发起HTTPS请求，请求证书
- Charles拦截客户端的请求，伪装成客户端向服务器进行请求
- 服务器向客户端返回服务器的CA证书
- Charles拦截服务器的响应，获取服务器证书公钥，然后自己制作一张证书，将服务器证书替换后发送给客户端。 （这一步，Charles拿到了服务器证书的公钥）
- 客户端接收到charles的证书后，生成一个对称密钥，用Charles的公钥加密，发送给Charles(前提是客户端已经信任charles的证书)
- Charles拦截客户端的响应，用自己的私钥解密对称密钥，然后用服务器证书公钥加密，发送给服务器。 （这一步，Charles拿到了对称密钥）
- 服务器用自己的私钥解密对称密钥，向Charles发送响应
- Charles拦截服务器的响应，替换成自己的证书后发送给客户端
- 至此，连接建立，Charles拿到了 服务器证书的公钥 和 客户端与服务器协商的对称密钥，之后就可以解密或者修改加密的报文了。
参考文献
cheapsslsecurity.com/blog/digita…
结尾
如果分享的内容对大家有帮助，欢迎点个赞支持一下。
