从https的演进到burpsuite抓包的漫谈

Posted 2021-04-30 湖心亭看雪落

当前浏览器不支持播放音乐或语音，请在微信或其他浏览器中播放        

        开始先抛出一下三个问题：

 

        网站登录用户名密码明文传输，改用https协议是否能解决这个问题？

        那为什么我采用https了通过burp还是可以看到明文密码？

        如果我在burp里看到的是明文密码，那我采用https的目的是什么呢？

 

        最近和新同学的交流中被我这三个问题问的比价懵，在测试中就会造成误报，当然像我这样的也可以强行解释通但这并不是该有的态度，在此利用跨年值守的时间整理了一下这个过程，发现能说清楚到完整的写出来中间的过程还很漫长，当然这个文章写得很啰嗦，专有名词上很不严谨，在技术细节上较粗糙，欢迎指正（文中的我和你都是为了区别两个不同的身份，这个体现在我平常的口语中）。

 

        HTTPS主要由有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。

 

        模拟web数据传输的几个阶段

1.完全明文传输的阶段

        http明文形式的传输如图所示，可以想象成burpsuite里的request和response。

        问题：任何人只要能抓取到我的流量，都可以像上图一样看到我详细的传输信息，这样的话密码就可以改名文明码了，基本失去了其功能。

2.对称性加密的阶段

这个过程就是在我发送我的http请求时，我先把本地生成的会话密钥发送给服务器（服务端反之），然后我再把用该密钥加密的http请求发送，服务器再用之前获取的客户端密钥解密得到明文请求（或反之）。

一个问题：这个本地生成的密钥如何共享给对方

两种方式：

带内：请求真实数据前先发送密钥信息，这个时候发送的信息只能是明文吧，我可不是只能抓取真实数据，你传送的密钥数据包照抓不误，然后你用该密钥加密的数据还有意义嘛？

带外：很简单，当你想要访问百度的时候呢，先拿U盘去西二旗考一下百度的密钥，然后在回去交给你的浏览器，这样的话，过不了多时，你就以带外传输密钥的借口环游世界了。

3.非对称加密阶段

        话说上有政策下有对策，好像不对，应该是办法总比问题多，这个时候出来了一种非对称加解密的算法，至于原理不搞密码学暂时不用管当然我也不懂，在这里明白一点，我作为服务器本地生成一对公私钥，公私钥之前只能互为对方加解密；然后我将公钥发给你，你所有的请求都用该公钥加密，而私钥只存在我手里，只有我收到你的请求才能正常的解密得到明文数据进行处理。

        问题：加密方式强度的增大，一方面靠加密算法的改进另一方面还要靠加密位数的大小。攻防始终是个博弈的过程，当我有次买票时看到12306的16张图片验证码时我就X掉了浏览器没有再买票了。非对称加密是个很耗时的过程，假设一次加解密用时3秒，意思可以理解为你去点击一个链接时需要等待2秒才可以看到返回结果，有没有想过任何一个链接都如此，第一批90后真的受不了！

4.非对称加密+对称加密

        虽然说非对称加密是非常耗时的，但是他呢确实可以安全的将信息发送给所要的人而不被窃听，那也当然可以通过这种方式把我本地生成的密钥安全的传递给对方呢，这样就解决了2中密钥传送的历史问题。既不用跑去西二旗也不怕被网路监听了，当双方都安全的拿到密钥时，对称加密就可以粉墨登场了，之后我才是主角。

        有没有问题：利用非对称加密方式获取密钥的前提是首先要拿到对方的公钥，理论上这个公钥可以发给任何人你也可能收到任何人的公钥，怎样确实你收到的公钥就是你自己的呢？

5.中间人攻击

        在这个图中，当客户端请求服务端的公钥时被中间人截获，中间人返回了自己本地生成的公钥，客户端也就只能将本地生成的对称密钥使用该公钥加密发送出去，中间人收到时呢私钥解决拿到该对称密钥之后的任何加解密就不是问题了；同时呢，中间人伪装客户端请求服务端的公钥，模拟客户端与服务器的数据在这里加密、解密、加密……

6.SSL证书完整性和真实性的验证

        SSL证书只是其中的一种，用于加密HTTP协议，也就是HTTPS。SSL证书负责传输公钥，是一种PKI（Public Key Infrastructure，公钥基础结构）证书。这些证书都是由受认证的证书颁发机构——我们称之为CA（Certificate Authority）机构来颁发， CA机构颁发的证书都是受信任的证书，对于SSL证书来说，如果访问的网站与证书绑定的网站一致就可以通过浏览器的验证而不会提示错误。

 

        在申请SSL证书时需要向CA机构提供网站域名，营业执照，以及申请人的身份信息等。网站的域名非常重要，申请人必须证明自己对域名有所有权，一个证书一般只绑定一个域名，CA机构也提供申请通配符域名（例如，*.baidu.com），通配符域名相当于绑定了主域名下的所有域名。

下面以百度的证书举个栗子：

        当我们访问百度时，可以看到浏览器URL栏中的一个锁，点击它即可查看百度的证书信息，如下：

        在图中可以看到证书的唯一目的：保证远程计算机的身份

        颁发给：baidu.com    这样的话www.baidu.com/map.baidu.com等都可以用

        之后还有颁发者信息和有效日期

        如果个人网站只为加密传输也可以自己制作SSL证书，自己制作的证书不会受到浏览器的信任，在访问的时候由于证书验证失败而给出警告，添加信任即可。

        证书路径：我们可以这样理解，根CA机构就是一个公司，根证书就是他的身份凭证，每个公司由不同的部门来颁发不同用途的证书，这些不同的部门就是中级CA机构，这些中级CA机构使用中级证书作为自己的身份凭证，其中有一个部门是专门颁发SSL证书，当把根证书，中级证书，以及最后申请的SSL证书连在一起就形成了证书链，也称为证书路径。

         根证书是最关键的一个证书，如果根证书不受信任，它下面颁发的所有证书都不受信任。操作系统在安装过程中会默认安装一些受信任的CA机构的根证书，可以在“运行”里面运行“certmgr.msc”启动证书管理器，如下图所示：

        当访问某个站点时浏览器收到数字证书，首先去判断该证书的颁发机构是否在我的受信任的机构中，如果不在浏览器中直接警告用户；如果在的话，1方面用CA公钥解密数字签名得到消息摘要，再将server公钥利用相同的hash算法再次得到一个消息摘要，对比两次的结果保证证书的完整性，下图这个样子：……

7.https通信过程

        该过程仅以图展示还比较条理：

        至此回到之前的问题

        1.网站已采用https协议，就不存在密码明文传输的问题了，不要忘了你的修复建议里写的是采用前端浏览器加密或采用https，当然完全可以劝导客户在采用https的时候继续做浏览器端的加密

        2.为啥https时burpsuite还是能看到明文的密码呢，这个参考中间人攻击，中间人维护了两对加解密钥，但是我们要花了很大篇幅去说SSL证书的问题还是实现了中间人攻击，在这里有个很重要的前提，我们在测试https的站点时会将burpsuite的证书导入到浏览器中，这样我们主动信任了burp证书，直接欺骗了浏览器说这是个可信仍的证书；所有当你在访问一个正当的网站提示说证书有问题时就要好好想一下要不要继续访问了。

        3.第三个问题自然就不用回答了。

 

卒章显志

        新的一年是不是还应该来点寄语呢，想了半天结果还是之前的吧，千虑一得：

 

        最后最后，该文纯手码字，徒手示图，如果看了有所启发给个一两毛的打赏吧，让我在这个跨年夜之后也能感受到新年的欢庆……