我们在通过 Appache mod_proxy 发布基于 Windows 的 VisualSVN 服务器时遇到了问题。
公司 IS 政策不允许从外部网络发起 SSL 连接并未经终止就进入公司网络。为了允许外部方发起 SSL 连接，他们使用 Apache mod_proxy 接受 SSL 连接并将其转换为另一种协议（例如 HTTP），然后将其转发到适当的内部资源。此服务作为所有外部发布资源的代理运行，因此对安全性和可用性都非常敏感。从我们团队的角度来看，我们看到的是，我们发布此服务的基础设施 100% 正常运行。我们能够模拟进入服务器的外部连接，所有数据都已返回，并且可以使用 Internet Explorer 或 TortoiseSVN 等存储库浏览工具按预期运行。
问题似乎出在前面提到的 mod_proxy 中；由网络团队运行。与 SVN 服务器的简单 HTTP 连接运行良好。但是，一旦我们尝试使用需要扩展 HTTP 协议的工具（例如 TortoiseSVN），一切都会崩溃。WireShark 显示正在使用的协议是 HTTP/XML，并且对资源的请求根本没有到达 VisualSVN 服务器。
是否有人知道是否需要特殊的配置选项才能使 mod_proxy 与 TortoiseSVN 等 WebDAV 工具协同工作？
以下是通过 IE 浏览时发生的情况：
客户端上启动的 SSL Connetctopn ---> mod_proxy -- 将请求转换为端口 80 --> ISA Server 2006 --> VisualSVN 返回网页
奇迹般有效。
这是我们尝试使用 Tortoise 浏览时看到的内容：
客户端发起的 SSL 连接 ---> mod_proxy没有数据包发送到 ISA 服务器
答案1
WebDAV 使用了许多 HTTP 方法，这些方法超出了您在正常网络流量中看到的范围，但您的 IE 连接并未使用这些方法。我猜？这些方法中的部分或全部在代理服务器中被阻止了。
什么响应会被发送回 Tortoise（应该显示在错误消息中，以及具体失败的方法；可能PROPFIND）？我猜是 403。
顺便说一句，告诉制定该政策的人，内部解密所有会话是错误的；如果他们真的需要监控纯文本流量，他们可以向监控设备提供相关私钥的副本，而不会损害连接的端到端完整性。攻击者不仅仅来自外部。