我最近开始使用具有免费许可证和专业许可证的安全工具（Burpsuite 1.5）。从其供应商网站下载免费的（我正在使用 BackTrack）后，我注意到在我的 Wireshark 中，每次启动该工具时，都会在其端口 443 上与供应商的 IP 建立 TLS 连接。此连接保持打开状态并且只要工具保持打开状态，就可以交换信息。因为我不知道正在传输什么，所以我阻止了防火墙上到该 IP 的传出流量：这不会影响其可用性。这可能是偏执狂、无知或两者兼而有之，但我认为我不希望这种情况发生。
我花了几个小时的研究来看看供应商是否会说些什么，这让我无处可去：也许我没有正确搜索，但从学习的角度（以及从安全性的角度来看）我对此很感兴趣观点也是如此，但在这种情况下程度较小）。我还没有直接联系供应商，主要是因为我想先了解它，所以如果这超出了这里的范围，我深表歉意。但是，如果我可以提出一个问题：
有没有办法找出正在发送的内容？
除了阻止我的防火墙上的连接之外，有没有更优雅的方法来阻止这种情况的发生？
您可以查看的一件事是在 burp 中设置上游代理（burp 的另一个实例或类似工具），然后查看流量是否通过该代理发送。另一方面，它可能会遇到 SSL 证书有效性问题。假设它工作正常，它会让您在 SSL 流中看到（尽管当然可以进一步加密）。
要阻止通信，您可以在主机文件中添加它正在联系的 DNS 名称的条目，并将其重定向到 127.0.0.1 作为一种选择。您也可以在您的主机防火墙上阻止它，或者如果您通过我上面提到的链式代理运行它，您也可能会阻止那里的流量（取决于您使用的工具。）
我建议的另一件事是在PortSwigger 论坛中提问，它们通常反应迅速，因此您很可能会在那里得到答案。
Burp Suite 是用 Java 编写的；Java 字节码很容易进行逆向工程，以至于可以编写反编译器。查看 Burp Suite 的内部结构将是确定发生了什么的最直接方法。
逆向工程的法律框架因国家/地区而异。在欧洲，只要是出于互操作性目的，它往往是被允许的——这并不真正适用于您的情况。因此，确定发生了什么的最安全方法是询问供应商。
另一种可能被认为与逆向工程无关的方法是拦截 SSL/TLS 层。这假设 Burp Suite 不包含自己的 SSL/TLS 代码，而是使用 Java 提供的支持。在 Java 架构中，这使用providers；默认 SSL/TLS 提供程序是SunJSSE. 也许添加您自己的提供商并注册为默认就足够了；或者也许SunJSSE在你的虚拟机中修改就可以了。无论哪种方式，您控制的提供者都可以将交换的数据记录在文件中。可能 Burp Suite 不仅使用SunJSSE而且还使用 JVM 中包含的“根 CA”的默认存储来验证服务器的证书；在这种情况下，您只需要制作自己的 CA，然后安装它，为目标服务器制作假证书，然后使用Fiddler获取数据。这将是确定正在发生的事情的最快方法。
当这种事情发生时，我总是首先去的地方是许可证。看起来 2.2.6 阻止我们进行逆向工程并在 javacode 中四处寻找以查看这段代码的作用......
在这个许可证中我没有看到任何其他允许回拨功能的许可证，而且它是一个质量很差的许可证，因为没有提及它。