【Https（一）】理论

因为网络是不安全的，直接使用Http协议，会有如下问题：

1.明文传输；如果信息被第三方截获，信息会被泄露；

2.信息完整性；如果信息被第三方截获，信息可能被篡改；

3.身份验证；交互的双方无法确认对方的身份，可能有第三方冒充；

那么Https又是如何解决以上问题呢？

针对问题1：交互双方在握手阶段，使用非对称加密算法交换秘钥，后续的信息传递使用该秘钥进行对称加密；

针对问题2：在发送信息时，附带签名。签名计算方式：包含两步，1. 将信息内容M使用某一哈希函数计算得到hash值H，2. 使用私钥加密hash值H得到签名sig，所以这里的签名不仅仅是hash值，算法有sha1witchrsa。接收方收到M+sig后，需要校验sig，过程如下：根据信息内容M重新计算hash值H1，再用发送方的公钥解密sig值得到原始hash值H，判断H和H1是否相等，如果相等说明信息没有被篡改；（这里光计算信息的hash值无法保证完整性，因为黑客可以把内容篡改，生成新的hash值。所以必须把hash值加密，这样即使黑客重新计算了hash值，但是由于不知道发送方的私钥，所以无法将新的hash值正确加密，那么接收方会校验失败）。

参见：​​https://www.docusign.com/how-it-works/electronic-signature/digital-signature/digital-signature-faq​​

针对问题3：这里首先展开说明一下身份验证问题，这个问题其实就是证明你看到的网站就是你希望访问的那个网站。举例，用户UserA需要访问站点B，但是黑客H冒充（方式有很多，比如DNS劫持，钓鱼网站等等）B的身份，同UserA进行通信，UserA的信息等等全部被黑客H截获。那么这个问题如何解决？这里以客户端验证服务端身份为例说明。

显然，站点B需要将自己的身份信息identification返回给UserA让其确认，身份信息包括但不限于网站域名、网站公钥等一些基本信息。

方式一：

站点B需要按照2里的方式，对自己的identification签名，这样UserA就可以使用B的公钥来验证其身份。但是这样做是有问题的，因为黑客H可以用自己的公钥将自己的identification进行签名发送给UserA，UserA可以验证成功，这样黑客还是冒充成功了。

方式二：

所以这里需要引入第三方机构CA来对站点B进行身份证明。CA就是专门来给别人做身份证明的机构。CA会用自己的私钥对网站身份的hash值做加密，生成证书certificate。

用户UserA在访问站点时，站点会将身份信息连同被CA签发过的certificate返回给用户，用户就可以用CA的公钥来解密certificate，从而验证身份信息。由于黑客不知道CA机构的私钥，所以签发的证书无法使用CA公钥验证成功。但是这里还是有问题，用户拿到的CA公钥可能被黑客伪造，这样黑客使用自己的秘钥对签发假的证书，用户仍然可以验证成功。

所以，CA证书都是预装到用户的操作系统以及浏览器中，以保证用户拿到的CA公钥的真实性（所以不要安装盗版系统？）。通过系统预装CA公钥的方式，可以保证用户可以拿到CA的真实公钥。这样，黑客就无法伪造身份了。不过这里还有一个问题：站点的证书是公开的，那么黑客可以直接拿到并在自己的站点进行下发，这样其实还是可以伪造站点？。核心点是黑客无法拿到站点的私钥，无法解密客户端发送的信息。

当然，这里其实还涉及到根CA证书以及证书链的概念。或者这么说，CA签发的证书是有分类的：root certificate，intermediate certificate以及end-user certificate。每一种证书的签发机构不同，最顶层的根证书全球只有几个CA机构可以签发，他们会生成根证书，给一些中间机构签发中间证书，而我们的站点的证书又是由这些中间证书来签发的。所以这里形成了一个证书链。

为什么需要证书链？因为根CA的私钥只有一个，所以为了保护私钥，并不会直接使用根CA签发网站证书，于是便引入了中间CA。中间CA的证书由根CA签发，网站的证书由中间证书签发。例子：我们可以看下百度站点的证书：

可以看到，百度的证书是由GlobalSign nv-sa机构来签发的，证书链的第二层就是该机构的证书：

该证书又是由GlobalSign Root CA来签发的。所以百度的证书需要由GlobalSign的中间证书的公钥解密验证，而GlobalSign的中间证书又需要根证书来验证。系统只需要预装根CA及中间CA的证书即可。

https协议栈

在http及tcp协议中间加入了ssl/tsl协议，处理以上讨论的加密签名等过程。 

https握手过程

客户端发送hello信息，包含支持的加密套件、客户端随机数等信息；

服务端回复hello信息，包括支持的加密套件、服务端随机数、证书等信息；

客户端验证证书，生成pre-master，使用服务端公钥加密发送给服务端；

双方使用pre-master，客户端及服务端随机数三个信息生成master key用户数据交换；

双方使用秘钥发送测试数据；

​​https://xz.aliyun.com/t/2530​​

​​https://xz.aliyun.com/t/2531​​

​​https://linux.cn/article-7289-1.html​​

​​https://cloud.tencent.com/developer/article/1425339​​

关于charles等代理的抓包原理：charles作为中间人，代理客户端与服务器发请求，然后将自己的证书代替服务器的证书返回给客户端，但是charles的证书不会被客户端设备信息，所以需要手动添加charles证书，这样相当于客户端与charles进行了https握手，charles就可以解密客户端信息，并转发至服务器。