关于https原理思考和charls抓包https原理
1、https原理
废话少说，忽略探索过程（其实主要是看别人的文章），下面简要阐述我的理解。
-
首先客户端要和服务器进行通信，以前使用http，是明文的，很容易被中途获取数据，被查看、篡改、伪装。所以需要使用一种加密方式对通信内容进行加密。这个过程是对称加密，也就是双方协定一个秘钥，同时用来加密和解密。
-
但是，服务器对客户端一般是一对多的关系，不可能服务器跟每一个设备或者浏览器都用同一个密码，这样中间拦截的人很容易知道密码同样很容易破解数据。所以需要服务器跟每一个通信的对象协商一个秘钥用来给通信的信息进行加密，一般是一个随机串。
-
但是，这个随机的串是什么要怎么协商呢？如果直接发给客户端，那如果协商秘钥又被拦截了不就还是一样被破解通信信息了，所以，需要对这个秘钥进行加密，如果还是使用对称加密的方式，那么还要告诉客户端给秘钥加密的秘钥是什么（又点绕），所以就又绕回到原来的问题。这时候我们不能再使用对称加密（同一个秘钥加密解密）的方式了，需要用到一种非对称加密（公钥、私钥一对秘钥）的方式，因为通过私钥加密的数据只有相应的公钥能解密，而公钥加密的数据只有私钥能解密，而服务器生成的一对公钥和私钥，只有公钥是在互联网中传递的，而私钥一直只有自己保存，这样，虽然服务器向客户端发送消息过程是不安全的，但却保证了从客户端到服务端过程是安全的（私钥只有服务器知道）。所以只要让客户端生成随机秘钥（对称加密算法），然后发给服务器，完成协商，就可以了。
-
但是，还是有问题的。如果中间有人，拦截了服务器发给客户端的公钥，然后自己生成了一对公钥和私钥，把服务器的公钥给掉包了，这样就可以使用自己的私钥进行解密，完成通信了。所以怎么保证服务器的公钥不会被掉包或者篡改呢？这时候就需要我们说的数字证书了。
-
数字证书是如何保证公钥不会被调包或者篡改呢？首先，证书是公司跟第三方公司申请的，包含很多公司的信息，然后加入服务器生成的公钥，再用第三方公司自己的私钥加密，只有用第三方公司提供的公钥可以解密，而这些第三方的公钥是存储在我们操作系统或者客户端本地的，所以可以解密然后拿到证书中公司服务器最初产生的公钥。
-
可能有人会问（比如我自己），既然客户端有第三方机构公开的公钥，那中间人也能拿到，在服务器返回证书给客户端的时候直接那公钥解密证书不就拿到服务器要传给客户端的公钥了？然后不就可以偷梁换柱了？但是你可能忘了，此时客户端要的不是公钥了，而是证书，你给他公钥没用，哈哈哈。
-
也许有人会问，那中间人也从第三方公司申请证书，然后中间替换掉原来的证书不就可以像调包公钥那样完成数据窃取了？当然是不行的，因为每个公司申请的证书是唯一的，浏览器或者客户端在请求服务器的时候，如果不是指定证书是不能通过的。简单点说就是验证正在访问的服务器地址（或者其他标识）和证书中的服务器地址（或者其他标识）是否一致。
-
那么新的问题来了，我怎么知道证书是不是我要证书呢？？有没有被中途篡改？？原因是证书有一套自己检验的机制，就是利用证书中保存的某些数据+证书生成证书编号的算法，然后自己生成一个证书编号，再和证书出厂时候的编号（也是加密的）进行比较，如果对的上就说明证书是有效的，没有被篡改过。
-
有人反映说不够清晰，所以从网上找了一张过程原理图，希望能让读者看的更加清晰。
屏幕快照 2017-10-28 下午6.27.35.png
2、charls如何抓去https的明文包
上面讲了https如何的安全，现在又说可以用charls工具抓包获取明文信息，这不是很矛盾？如果charls能做到，那不是很多人都可以做到从通讯中途获取数据？那是不是说https没用，跟http是一样不安全的？可是上面https的原理明明感觉很安全了，我们又如何能够在这么安全的情况下截取数据呢？
-
先附上一张网上其他人的原理图
v2-a89764317e9b82ffc3c459626b16a136_hd.jpg -
看的不是很明白？没关系，下面用一句话回答一下上面的问题。哈哈哈
-
有些人认为https可以完美防止中间人攻击，无法抓到https的明文包...... 其实是不对的，TLS的设计只能说是从技术上最大限度地保护网络报文的安全，它无法防止用户自己作死。
-
从第一部分https原理知道，最后保证安全的其实是我们客户端（浏览器）对服务端返回的证书的校验，但是如果我们客户端本地用户手动信任了某第三方证书，那么校验就直接通过了，自然也就能够获取到数据了。当然charls具体的原理没有我说的这么简单，但用charls抓过https包的人都知道，第一步就是要我们手动信任charls的证书（具体使用步骤请自行百度，有很多教程）。所以，也就解释了为什么https是无法防止用户自己作死的。
至此，终于码完了，过程描述比较复杂（写得比较粗陋），将就看吧。此外，手机码字好辛苦。有疑问欢迎指教，有不足之处欢迎指证。不喜勿喷
作者：静静code的蜗牛小小
链接：https://www.jianshu.com/p/b0bee2fa1e10
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
客户端向服务器发起HTTPS请求
Charles拦截客户端的请求，伪装成客户端向服务器进行请求
服务器向“客户端”（实际上是Charles）返回服务器的CA证书
Charles拦截服务器的响应，获取服务器证书公钥，然后自己制作一张证书，将服务器证书替换后发送给客户端。（这一步，Charles拿到了服务器证书的公钥）
客户端接收到“服务器”（实际上是Charles）的证书后，生成一个对称密钥，用Charles的公钥加密，发送给“服务器”（Charles）
Charles拦截客户端的响应，用自己的私钥解密对称密钥，然后用服务器证书公钥加密，发送给服务器。（这一步，Charles拿到了对称密钥）
服务器用自己的私钥解密对称密钥，向“客户端”（Charles）发送响应
Charles拦截服务器的响应，替换成自己的证书后发送给客户端
至此，连接建立，Charles拿到了 服务器证书的公钥 和 客户端与服务器协商的对称密钥，之后就可以解密或者修改加密的报文了。
HTTPS抓包的原理还是挺简单的，简单来说，就是Charles作为“中间人代理”，拿到了 服务器证书公钥 和 HTTPS连接的对称密钥，前提是客户端选择信任并安装Charles的CA证书，否则客户端就会“报警”并中止连接。这样看来，HTTPS还是很安全的。
————————————————
版权声明：本文为CSDN博主「zhong_wenjun」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zwjemperor/article/details/80719427
