我已经为我们编写了一个使用Python的twisted网络框架的代理示例，我发现twisted提供了对代理内部的适当控制，而所需模板却很少。为了实现此目的，它引入了一些自己的新抽象。这些抽象使twisted代码非常简洁，但对于不熟悉的人来说又有点神秘。

　　Twisted是围绕“事件驱动的回调”而设计的。这意味着只要发生特定事件，它就会自动运行特定方法（或“回调”）。我们感兴趣的事件是“构建连接”和“接收数据”。我们可以通过使用称为connectionMade和dataReceived的方法定义一个Protocol类来告诉twisted事件发生时该怎么办。当twisted看到“连接已构建”事件时，它将运行我们的connectionMade方法，你可能会猜到看到“数据已接收”事件时它将做什么。

　　TCPProxyProtocol是我们的主要协议类，它处理与智能手机的通信，并将与远程服务器的通信委托给ProxyToServerProtocol类。我们通过实例化其中一个TCPProxyProtocol对象来初始化代理服务器，并告诉twisted使用它来监听端口80（按照规定，这个端口是未加密的HTTP端口）。接下来，什么都不会发生，直到你的笔记本电脑在端口80（可能是通过智能手机）上收到TCP连接为止。当twisted看到此“连接构建”事件时，它将在我们的TCPProxyProtocol上调用connectionMade回调。至此，我们的代理已与你的智能手机构建连接，并且完成了4步过程的第1步。

　　如果我们的TCPProxyProtocol在ProxyToServerProtocol与远程服务器的连接完成之前从你的手机接收到任何数据，它会将数据添加到缓冲区中，以确保数据不会被删除。一旦连接就绪，ProxyToServerProtocol将缓冲区收集的所有数据发送到远程服务器。此时，我们的代理已经打开了与你的智能手机和远程服务器的独立连接，并将数据从你的智能手机发送到远程服务器。此时，步骤2完成。

　　由于我们还没有为我们的代理实现TLS支持，我们需要使用一个没有启用HTTPS的网站来测试我们的代理。我建议使用nonhttps.com，这是一个非常方便的开发主机名，正如承诺的那样，它不使用HTTPS。

　　然后启动这两个脚本，并在手机上访问nonhttps.com。你应该看到你的虚假DNS服务器欺骗了DNS请求，并返回了笔记本电脑的IP地址。然后，你应该看到TCP代理从智能手机接收HTTP数据，并将其内容记录到终端。接下来，它将记录从nonhttps.com返回的相应HTTP响应。最后，nonhttps.com应该会加载到手机的浏览器中，仿佛什么事都没有发生。

　　你是否可以使用DNS服务器和TCP代理日志来准确指出问题出在哪里？也许你的DNS欺骗失败了，或者除了从远程服务器接收回数据之外，一切都在正常工作？

　　打开Wireshark并使用过滤器tcp端口80运行它，你看到任何看起来像错误的东西吗？你看到什么了吗?

　　接下来，你可以代理任何不使用TLS加密的TCP请求。即使我们一直在使用HTTP请求进行测试以简化操作，但请注意，在我们的代码中甚至没有提到HTTP。我们只看到一个通用的tcp传输的字节流，它可以具有任何结构并使用其喜欢的任何应用程序协议。

　　这是构建通用TCP代理的最后一部分，该代理将能够处理任何基于TCP的协议，而不仅仅是HTTP。

　　如上所述，我们已经完成了可处理未加密协议的基本TCP代理的构建。我们使用此代理来拦截和检查你手机发送的纯文本HTTP请求，并且效果很好。

　　但是，我们的代理仍然无法处理加密，包括TLS，这是互联网上最常见的加密形式。你手机上任何需要TLS加密连接的应用程序，比如连接到只支持https的网站的移动浏览器，都将拒绝与我们的代理进行业务往来。因此，我们需要向我们的代理展示如何协商TLS连接。

　　现在，我们将建立一个伪造的证书颁发机构。这将帮助我们诱骗你的手机相信它应该信任我们的代理，并帮助我们的代理与你的手机建立TLS连接。

　　让我们尝试通过基本代理发送HTTPS请求，将虚拟的DNS服务器中的目标主机名从第2部分更改为google.com。同样，将我们的代理服务器中的主机名也从第3部分更改为google.com，并将其监控和发送的端口设置为443（按照规定，为HTTPS端口）。将你手机的DNS服务器设置为你笔记本电脑的本地IP地址，然后同时启动我们的DNS服务器和TCP代理。

　　在手机上访问google.com，如上所述使用nonhttps.com执行这个技巧时，会话劫持会成功发生。你的手机浏览器将其对nonhttps.com的未加密请求发送到我们的代理，没此时，代理将此请求转发到nonhttps.com本身。

　　但是，Google非常明智地坚持通过HTTPS提供服务。当你手机的浏览器发现我们的代理不知道如何协商TLS连接时，它将立即放弃并关闭与它的TCP连接。此时，浏览器将显示一个错误。

　　首先，我们列出需要解决的挑战。我们将从代理的当前状态开始，然后向前回溯。这将帮助我们确切地了解为什么每一步都是必要的，如果我们将其遗漏，将会发生什么。

　　这些方法的不同之处在于它们与客户端建立TCP连接后如何进行，listenTCP立即开始接受应用程序层数据（例如未加密的HTTP请求）。但是，在listenSSL接受任何应用程序层数据之前，它首先尝试与客户端执行TLS握手。仅在成功完成此握手之后ip代理和vpn，listenSSL才开始接受（现已加密）应用程序层数据。

　　为了了解我们的代理TLS，我们将需要使用listenSSL而不是listenTCP。但是，除了在我们的方法调用的末尾添加SSL外。

　　listenSSL为我们处理TLS握手和解密的底层算法机制，但是为了做到这一点，需要向它传递一个表示TLS证书的对象和一个私有密钥作为它的一个参数。我们将会看到，这些对于我们来说很容易创建，但正确率不敢保证。

　　服务器使用TLS证书来证明其身份，当客户端（例如你的手机）要求服务器（例如我们的代理）执行TLS握手时，服务器首先向客户端提供其TLS证书。你的手机将拒绝与我们的代理进行TLS握手，除非此证书的公用名（证书中的字段）与你认为手机正在与之交谈的主机名匹配。因此，我们将需要能够生成和使用我们自己的TLS证书，将它们的公共名称设置为目标应用程序的主机名(如api.targetapp.com)。

　　这听起来可能有些奇怪，TLS的全部意义在于，当服务器向客户端提供api.targetapp.com的证书时，客户端可以非常确定它正在与真正的TargetApp对话，而不是某个虚假的恶意中间人。首先，我们不是恶意中间人，但是如果我们能在舒适的家里为api.targetapp.com生成一个证书，那么这对TLS的安全来说肯定不是一个好兆头吗？