关于安全性：代理服务器可以缓存SSL GET吗？ 如果没有，响应主体加密就足够了吗？

(||任何)代理服务器是否可以缓存客户端通过https请求的内容？ 由于代理服务器看不到查询字符串或http标头，因此我认为它们看不到。

我正在考虑一个桌面应用程序，该应用程序由其公司代理背后的许多人运行。 该应用程序可能会跨Internet访问服务，我想利用内置的Internet缓存基础结构来进行"读取"。 如果缓存代理服务器无法缓存SSL传递的内容，那么仅加密响应的内容是否可行？

我正在考虑通过http请求所有我们希望可实现的GET请求，并使用非对称加密对主体进行加密，其中每个客户端都有解密密钥。 每当我们希望执行不可缓存的GET或POST操作时，都将通过SSL执行。

罗里(Rory)评论说，如果代理不是绝对正确，则代理必须使用自签名证书。

可以将代理实现为为每个要处理的SSL主机生成一个新证书，并使用一个通用根证书对其进行签名。在OP的适当环境中，可以很容易地将通用签名证书作为受信任的CA安装在客户端计算机上，并且他们很乐意接受这些"伪造的" SSL证书用于代理的流量，因为不会出现主机名不匹配的情况。

实际上，这正是诸如Charles Web调试代理之类的软件如何检查SSL流量而不会在浏览器中引起安全性错误等的方式。

不，不可能直接缓存https。客户端和服务器之间的整个通信都是加密的。代理位于服务器和客户端之间，为了对其进行缓存，您需要能够读取它，即解密加密。

您可以做一些缓存。基本上，您在代理上执行SSL，拦截发送给客户端的SSL。基本上，数据是在客户端和代理之间加密的，解密，读取和缓存的数据是加密的，然后在服务器上发送的。来自服务器的答复同样被解密，读取和加密。我不确定您如何在主要的代理软件(如鱿鱼)上执行此操作，但是有可能。

这种方法的唯一问题是代理将必须使用自签名证书将其加密到客户端。客户端将能够告诉中间的代理已读取数据，因为证书不是来自原始站点。

检出www.bluecoat.com是一个商业代理，实际上它可以进行https拦截，以阻止站点，限制内容，检查病毒和缓存内容(GET)

I think you should just use SSL and rely on an HTTP client library that does caching (Ex: WinInet on windows). It's hard to imagine that the benifits of enterprise wide caching is worth the pain of writing a custom security encryption scheme or certificate fun on the proxy. Worse, on the encyrption scheme you mention, doing asynmetric ciphers on the entity body sounds like a huge perf hit on the server side of your application; there is a reason that SSL uses symmetric ciphers for the actual payload of the connection.

有关的应用程序不是浏览器应用程序，而是桌面应用程序，可通过Internet提取数据。即将发生的事情是该应用程序的所有实例都将在大约同一时间提取同一块。此数据需要保护，但我希望通过使应用程序的某些实例从公司代理服务器获取缓存的版本来提高性能。

数据块很小，但是可能会经常请求它们。基本上，所有应用程序实例都将同时请求彼此相同的数据。

服务器端的数据/消息主体将被预先加密并缓存在分布式内存哈希表中。不会根据每个请求执行加密。

我也在研究使用消息总线，例如NServiceBus。

我认为您应该只使用SSL并依赖进行缓存的HTTP客户端库(例如：Windows上的WinInet)。很难想象企业级缓存的好处值得在代理上编写自定义安全加密方案或证书乐趣。更糟糕的是，在您提到的加密方案中，在实体主体上进行非对称加密听起来像是对应用程序服务器端的巨大打击。 SSL会将对称密码用于连接的实际有效负载是有原因的。

如何在应用程序服务器上在对https响应进行加密的组件后面设置服务器缓存？如果您有反向代理设置，这将很有用。

我在想这样的事情：