通过 HTTPS 浏览网站时，Web 浏览器通常在后台执行大量工作 - 协商安全通道、验证站点证书、验证信任链等。
如果您的浏览器配置为使用 Web 代理，则当前 HTTP 协议支持 CONNECT 方法 - 这使您的浏览器能够设置到网站的 TLS 隧道，而不会向代理透露任何请求内容（除了网站，当然）。
浏览器对代理服务器的身份做了什么？
如果代理没有证书，那么它可能会被中间人模拟。
即使代理确实有证书，如果没有检查它，它仍然可以模拟它。
协议（或任何配套的 RFC）是否定义了应该如何处理？常见的网络浏览器通常如何处理这个问题？
如果代理没有证书，是否有任何反馈给用户？如果代理确实有证书，但它是无效的，那么有反馈吗？
此外，即使请求是纯 HTTP，是否也有安全验证 Web 代理的规定？
例如，通过 HTTPS 连接到代理，即使对网站的请求是通过 HTTP...
请注意，我不是在问如何识别网站，无论是通过代理隧道还是让它拦截 SSL 链。
相反，我想验证代理本身的身份，以确保没有未经授权的服务器正在攻击我......
按照惯例，让我们首先回答所提出的确切问题。
目前，使用 HTTPS 连接到代理还没有得到广泛支持。squid 文档有一些关于这个主题的信息；总结一下：
Chrome 支持它，但它必须通过代理自动配置脚本进行配置，因为没有 GUI 支持。这也意味着不使用“系统范围的代理配置”。
Firefox 不支持它，尽管自 2007 年以来该功能已被标记为请求。（更新：在 FF 33+ 中支持）
在其他浏览器上没有任何指示，可以推测为“不支持”。
应该测试 Chrome 在遇到代理的“有点无效”证书时会做什么，但它可能取决于确切的浏览器版本（它一直在变化，通常是透明的）、操作系统（因为证书处理往往是委托给操作系统），以及证书在哪些方面无效（过期、错误的服务器名称、未知的信任锚……）。此外，这里还有一个先天先有鸡的问题：完整的证书验证，这是X.509所要求的，包括检查吊销，即下载路径中所有证书的 CRL。CRL 下载的 URL 通常位于证书本身中。但是，如果您为 HTTP 流量使用代理，则 CRL 下载将需要通过该代理...并且您尚未验证代理证书。没有鸡，没有蛋。
我们可能还注意到代理自动配置文件格式并不真正支持 HTTPS 代理。该文件没有正式的标准，但习惯是遵循旧的 Netscape 草案，该草案说 PAC 文件定义了一个 Javascript 函数，该函数可以返回代理主机名和端口，但不能返回协议。所以，没有HTTPS。对于 HTTPS 代理支持，Chrome 隐含地使用了对这一事实约定的扩展，方法是在它无权存在的地方填充 HTTPS URL，并希望浏览器从中理解。
按照惯例，让我们看看可以提出哪些替代建议。
为确保客户端和代理之间的通信受到保护，可能适用以下两种解决方案：
使用VPN。这是高度通用的，并且由于它在操作系统级别运行，因此将适用于所有浏览器。当然，它要求在客户端机器上安装该东西的人对该机器具有管理权限（您不能作为简单的非特权用户执行此操作）。
使用基于 SSH 的 SOCKS 代理。在您的客户端系统上，运行ssh -N -D 5000 theproxy：然后将您的浏览器设置localhost:5000为用作 SOCKS 代理。此解决方案要求您拥有代理服务器theproxy（
SOCKS 代理解决方案将确保流量通过代理机器，但不包括缓存，这也是我们通常首先要使用代理的原因之一。不过，它可以通过使用一些额外的工具来改变。SOCKS 代理是关于通过自定义隧道重定向所有 TCP/IP 流量（通常）。通过使用使用 SOCKS 的版本“替换”正常的操作系统级网络调用，可以对应用程序提供通用支持。实际上，这使用了一个特定的 DLL，该 DLL 被推送到标准 OS 库上；这在基于 Unix 的系统中受支持，LD_PRELOAD我想这也可以在 Windows 上完成。所以完整的解决方案是：
localhost:5000用作 SOCKS 代理。theproxy:3128用作普通的 HTTP 代理。然后，当浏览器想要浏览时，它会打开一个到 的连接theproxy:3128，DLL 会拦截该连接并将其重定向到它打开到的 SOCKS 隧道localhost:5000。此时，SSH 抓取数据并将其发送到theproxySSH 隧道的保护下。数据在 上退出theproxy，此时与端口 3128 的连接是纯本地的（因此不受基于网络的攻击者的影响）。
在 SSH-SOCKS 设置上添加缓存的另一种方法是应用透明代理。Squid 可以做到这一点（名称为“拦截缓存”）。
使用 SSH 保护进行缓存的另一种方法是使用 SSH 构建从您的机器到代理的通用隧道。运行这个：
ssh -N -L 5000:localhost:3128 theproxy
然后将您的浏览器设置为localhost:5000用作HTTP代理（不是 SOCKS）。这不会在 FTP 或 Gopher 等替代协议上应用代理，但是谁使用它们呢？
按照惯例，现在让我们质疑这个问题。
你说你想防止中间人攻击。但是，实际上，代理是一个中间人。您真正想要的是代理是唯一执行 MitM 的实体。浏览器和代理（或 SSH-SOCKS 或 VPN）之间的 HTTPS 只能保护客户端和代理之间的链接，而完全不能保护代理和目标 Web 服务器之间的链接。如果不考虑广域网（Wide Internet）上发生的情况，就声称可以可靠地阻止中间人攻击是冒昧的，众所周知，广域网是一个严酷的地方。
对于针对 MitM 的端到端保护，请使用 SSL，即浏览 HTTPS Web 服务器。但是，如果您这样做，那么对浏览器到代理链接的额外保护是多余的。
如果您考虑代理身份验证，保护浏览器和代理之间的流量是有意义的。一些代理在授予对其服务的访问权限之前需要明确的身份验证；这在大型组织中很常见（曾经？），它们希望为少数快乐的人（通常是老板和他最喜欢的下属）保留“无限制的 Internet 访问权限”。如果您向代理发送密码，那么您不希望密码被窥探，因此 SSL。但是，可以窃听本地网络的攻击者必然控制一台具有管理员权限的本地机器（可能是他自己带来的笔记本电脑）。他的令人讨厌的能力已经远远超出了对互联网带宽的简单窃取。此外，限制每个用户的 Internet 访问现代操作系统的基础映射相当差，后者往往依赖互联网访问来完成许多任务，包括软件更新。在每次使用的基础上更有效地控制互联网访问。
因此，我认为保护对 HTTP 代理的访问有一些优点，但仅限于相当不常见的情况。特别是，它与击败大多数 MitM 攻击几乎没有关系。
客户端的 Chrome 和代理端的 Squid 可以通过 https 工作。有关详细信息，请参阅安全 Web 代理。
我希望 Chrome 会警告您无效的代理证书，但没有此设置的经验，因此无法确认。
作为使用@Thomas Pornin 的答案（他建议使用 SSH）的替代方法，您可以使用服务总线来维护从本地端口到远程服务器的透明连接。
当代理客户端软件连接到服务总线时，就会发生“身份验证”……此服务总线的端点可以是任何东西，例如 Intranet、公司代理等。一旦客户端软件对您进行身份验证，一个 mini-vpn 就是创建（就像 SSH 一样）。
如何开始
此 .Net 客户端安装在本地，目标是代理或您需要信任的其他设备。
安装端口桥
注意：用您选择的端口在心理上替换 SQL 客户端和 1433 ......对于这个基于 TCP 的代理来说都是一样的
该项目允许多个经过 NAT 的服务器通过单个服务总线连接通过 Internet 访问多个经过 NAT 的客户端。
这是一个非常聪明的实现，它会真正让你思考。下面是源码
http://blogs.msdn.com/b/clemensv/archive/2009/11/18/port-bridge.aspx
...以及相同的另一种解释。
http://brentdacodemonkey.wordpress.com/2010/05/05/azure-appfabric-%e2%80%93-a-bridge-going-anywhere/
此外，codeplex 上有一个名为“SocketShifter”的相关项目：http ://socketshifter.codeplex.com/ 虽然 codeplex 网站建议使用 portbridge，但我确实看到了（2010 年 8 月）的签入，不确定哪个更最新。这可能值得调查。