甜橙安全头条第23期 | burpsuite为啥能解https的包

一、http为什么不安全？  

二、https如何保证安全

要解决http带来的问题，就要引入加密以及身份验证机制。

引入对称加密和非对称加密

这样是不是就一定安全？

中间人获取对称密钥的过程：

首先来看一种场景：小红发信息约小明放学后去电影

引入数字证书

数字证书有三个作用：

1.身份授权。确保浏览器访问的网站是经过CA验证的可信任的网站。

2.分发公钥。每个数字证书都包含了注册者生成的公钥（验证确保是合法的，非伪造的公钥）。在SSL握手时会通过certificate消息传输给客户端。

3.验证证书合法性。客户端接收到数字证书后，会对证书合法性进行验证。只有验证通过后的证书，才能够进行后续通信过程。

那么问题又来了，数字证书谁来校验？

引入数字签名

数字签名的制作和验证过程如下：

1.数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，然后使用CA自己的私钥对消息摘要进行加密。

2.数字签名的校验。使用CA的公钥解密签名，然后使用相同的签名函数对签名证书内容进行签名，并和服务端数字签名里的签名内容进行比较，如果相同就认为校验成功。

数字证书主要包含那些信息：
1.证书颁发机构
2.证书颁发机构签名
3.证书绑定的服务器域名
4.证书版本、有效期
5.签名使用的加密算法（非对称算法，如RSA）
6.公钥

Tip: 信息收集中基于SSL证书查询

（1）https://crt.sh/

（2）https://censys.io/

（3）https://developers.facebook.com/tools/ct/

（4）https://google.com/transparencyreport/https/ct/

看看我们自己的

总结一下：

那么问题又又来了，burp为啥还能抓到https的包？

6. 点击下一步直到完成 ,最后会弹出一个警告对话框，选择是即可。如下图是安装后的抓包效果。

原理解析

·客户端向服务器发起HTTPS请求。

·Burpsuite拦截客户端的请求，伪装成客户端向服务器进行请求。

·服务器向“客户端”（实际上是Burpsuite）返回服务器的CA证书。

·Burpsuite拦截服务器的响应，获取服务器证书公钥，然后自己制作一张证书，将服务器证书替换后发送给客户端。（这一步，Burpsuite拿到了服务器证书的公钥）

·客户端接收到“服务器”（实际上是Burpsuite）的证书后，生成一个对称密钥，用Burpsuite的公钥加密，发送给“服务器”。（Burpsuite）

· Burpsuite拦截客户端的响应，用自己的私钥解密对称密钥，然后用服务器证书公钥加密，发送给服务器。（这一步，Burpsuite拿到了对称密钥）

·服务器用自己的私钥解密对称密钥，向“客户端”（Burpsuite）发送响应。

·Burpsuite拦截服务器的响应，替换成自己的证书后发送给客户端。

·至此，连接建立，Burpsuite拿到了 服务器证书的公钥 和 客户端与服务器协商的对称密钥，之后就可以解密或者修改加密的报文了。

·HTTPS抓包的原理还是挺简单的，简单来说，就是Burpsuite作为“中间人代理”，拿到了 服务器证书公钥 和 HTTPS连接的对称密钥，前提是客户端选择信任并安装Burpsuite的CA证书，否则客户端就会“报警”并中止连接。这样看来，HTTPS还是很安全的。

挂代理与未挂代理证书区别

反抓包策略

· 证书锁定 需要在客户端代码内置仅接受指定域名的证书，而不接受操作系统或浏览器内置的CA根证书对应的任何证书，通过这种授权方式，保障了APP与服务端通信的唯一性和安全性，因此客户端与服务端（例如API网关）之间的通信是可以保证绝对安全。但是CA签发证书都存在有效期问题，缺点是在 证书续期后需要将证书重新内置到APP中。

· 公钥锁定 提取证书中的公钥并内置到客户端中，通过与服务器对比公钥值来验证连接的正确性。制作证书密钥时，公钥在证书的续期前后都可以保持不变（即密钥对不变），所以可以避免证书有效期问题，一般推荐这种做法。

突破SSL-Pinning抓包

四、sslsplit嗅探tls/ssl连接

1.工作原理

这里我们已经可以清晰看到我们的制作的根证书已经替换掉了服务器的官方证书。

五、http双向认证

1.客户端发起HTTPS请求，将SSL协议版本的信息发送给服务端

2.服务端去CA机构申请来一份CA证书，证书里面有服务端公钥和签名。将CA证书发送给客户端

3.客户端读取CA证书的明文信息，采用相同的hash散列函数计算得到信息摘要（hash目的：验证防止内容被修改），然后用操作系统带的CA的公钥去解密签名（因为签名是用CA的私钥加密的），对比证书中的信息摘要。如果一致，则证明证书是可信的，然后取出了服务端公钥

4.客户端发送自己的客户端证书给服务端，证书里面有客户端的公钥：C_公钥

5.客户端发送支持的对称加密方案给服务端，供其选择

6.服务端选择完加密方案后，用刚才得到的C_公钥去加密选好的加密方案

7.客户端用自己的C_私钥去解密选好的加密方案，客户端生成一个随机数（密钥F），用刚才等到的服务端B_公钥去加密这个随机数形成密文，发送给服务端。

8.服务端和客户端在后续通讯过程中就使用这个密钥F进行通信了。和之前的非对称加密不同，这里开始就是一种对称加密的方式。