Can a (||any) proxy server cache content that is requested by a client over https? As the proxy server can't see the querystring, or the http headers, I reckon they can't.
(|| any)代理服务器可以缓存客户端通过https请求的内容吗?由于代理服务器无法看到查询字符串或http标头,我估计它们不能。
I'm considering a desktop application, run by a number of people behind their companies proxy. This application may access services across the internet and I'd like to take advantage of the in-built internet caching infrastructure for 'reads'. If the caching proxy servers can't cache SSL delivered content, would simply encrypting the content of a response be a viable option?
我正在考虑一个桌面应用程序,由他们公司代理背后的许多人运行。这个应用程序可以通过互联网访问服务,我想利用内置的互联网缓存基础设施进行“读取”。如果缓存代理服务器无法缓存SSL传递的内容,那么只是加密响应内容才是可行的选择吗?
I am considering all GET requests that we wish to be cachable be requested over http with the body encrypted using asymmetric encryption, where each client has the decryption key. Anytime we wish to perform a GET that is not cachable, or a POST operation, it will be performed over SSL.
我正在考虑通过http请求所有我们希望可以缓存的GET请求,并使用非对称加密加密主体,其中每个客户端都有解密密钥。任何时候我们希望执行不可缓存的GET或POST操作,它都将通过SSL执行。
6 个解决方案
#1
22
The comment by Rory that the proxy would have to use a self-signed cert if not stricltly true.
Rory的评论认为,如果不严格,则代理必须使用自签名证书。
The proxy could be implemented to generate a new cert for each new SSL host it is asked to deal with and sign it with a common root cert. In the OP's scenario of a corportate environment the common signing cert can rather easily be installed as a trusted CA on the client machines and they will gladly accept these "faked" SSL certs for the traffic being proxied as there will be no hostname mismatch.
可以实现代理以为要求处理的每个新SSL主机生成新证书,并使用公共根证书对其进行签名。在OP的corportate环境中,常见的签名证书可以很容易地作为客户端计算机上的可信CA安装,并且他们很乐意接受这些“伪造的”SSL证书,因为没有主机名不匹配的代理流量。
In fact this is exactly how software such as the Charles Web Debugging Proxy allow for inspection of SSL traffic without causing security errors in the browser, etc.
实际上,这正是Charles Web Debugging Proxy等软件允许检查SSL流量而不会在浏览器中引起安全性错误的原因。
#2
17
No, it's not possible to cache https directly. The whole communication between the client and the server is encrypted. A proxy sits between the server and the client, in order to cache it, you need to be able to read it, ie decrypt the encryption.
不,不可能直接缓存https。客户端和服务器之间的整个通信都是加密的。代理位于服务器和客户端之间,为了对其进行缓存,您需要能够读取它,即解密加密。
You can do something to cache it. You basically do the SSL on your proxy, intercepting the SSL sent to the client. Basically the data is encrypted between the client and your proxy, it's decrypted, read and cached, and the data is encrypted and sent on the server. The reply from the server is likewise descrypted, read and encrypted. I'm not sure how you do this on major proxy software (like squid), but it is possible.
你可以做一些事情来缓存它。您基本上在代理上执行SSL,拦截发送到客户端的SSL。基本上,数据在客户端和代理之间进行加密,它被解密,读取和缓存,数据被加密并在服务器上发送。来自服务器的回复同样被解密,读取和加密。我不确定你是如何在主要代理软件(如鱿鱼)上做到这一点,但它是可能的。
The only problem with this approach is that the proxy will have to use a self signed cert to encrypt it to the client. The client will be able to tell that a proxy in the middle has read the data, since the certificate will not be from the original site.
此方法的唯一问题是代理必须使用自签名证书将其加密到客户端。客户端将能够告诉中间的代理已读取数据,因为证书不会来自原始站点。
#3
1
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.
我认为你应该只使用SSL并依赖于进行缓存的HTTP客户端库(Ex:Windows上的WinInet)。很难想象企业级缓存的好处值得在代理上编写自定义安全加密方案或证书乐趣。更糟糕的是,在您提到的加密方案中,在实体主体上执行异步密码听起来像是应用程序服务器端的一个巨大的打击;有一个原因是SSL使用对称密码来实现连接的实际有效负载。
The application concerned is not a browser app, it's a desktop app pulling data over the internet. What is going to happen is that all instances of the app will be pulling the same piece of at around about the same time. This data needs to be secured, but I'm hoping to increase perf by having some instances of the app get a cached version from the corporate proxy server.
该应用程序不是一个浏览器应用程序,它是一个桌面应用程序通过互联网提取数据。将要发生的是,应用程序的所有实例将在大约同一时间拉动相同的部分。这个数据需要得到保护,但我希望通过让应用程序的某些实例从公司代理服务器获得缓存版本来增加性能。
The data chunks are small, but they may be requested frequently. Essentially all app instances are going to request the same data as each other at the same time.
数据块很小,但可能经常请求它们。基本上所有应用实例都会同时请求相同的数据。
The data/message body on the server side will be pre-encrypted and cached in a distributed in-memory hash-table. Encryption will not be performed on a per-request basis.
服务器端的数据/消息体将被预加密并缓存在分布式内存中散列表中。不会基于每个请求执行加密。
I'm also investigating using a message bus, such as NServiceBus instead.
我也正在调查使用消息总线,例如NServiceBus。
#4
1
Check out www.bluecoat.com is a commercial proxy that in fact CAN do https interception in order to block sites, restrict content, inspect for viruses and cache content (GETs)
查看www.bluecoat.com是一个商业代理,实际上可以执行https拦截以阻止网站,限制内容,检查病毒和缓存内容(GET)
#5
1
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 benefits of enterprise wide caching is worth the pain of writing a custom security encryption scheme or certificate fun on the proxy. Worse, on the encryption scheme you mention, doing asymmetric 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.
我认为你应该只使用SSL并依赖于进行缓存的HTTP客户端库(Ex:Windows上的WinInet)。很难想象企业级缓存的好处值得在代理上编写自定义安全加密方案或证书乐趣。更糟糕的是,在您提到的加密方案中,在实体主体上执行非对称密码听起来像是应用程序服务器端的巨大冲击;有一个原因是SSL使用对称密码来实现连接的实际有效负载。
#6
0
How about setting up a server cache on the application server behind the component that encrypts https responses? This can be useful if you have a reverse-proxy setup.
如何在加密https响应的组件后面的应用程序服务器上设置服务器缓存?如果您具有反向代理设置,这将非常有用。
I am thinking of something like this:
我在考虑这样的事情:
application server <---> Squid or Varnish (cache) <---> Apache (performs SSL encryption)
#1
22
The comment by Rory that the proxy would have to use a self-signed cert if not stricltly true.
Rory的评论认为,如果不严格,则代理必须使用自签名证书。
The proxy could be implemented to generate a new cert for each new SSL host it is asked to deal with and sign it with a common root cert. In the OP's scenario of a corportate environment the common signing cert can rather easily be installed as a trusted CA on the client machines and they will gladly accept these "faked" SSL certs for the traffic being proxied as there will be no hostname mismatch.
可以实现代理以为要求处理的每个新SSL主机生成新证书,并使用公共根证书对其进行签名。在OP的corportate环境中,常见的签名证书可以很容易地作为客户端计算机上的可信CA安装,并且他们很乐意接受这些“伪造的”SSL证书,因为没有主机名不匹配的代理流量。
In fact this is exactly how software such as the Charles Web Debugging Proxy allow for inspection of SSL traffic without causing security errors in the browser, etc.
实际上,这正是Charles Web Debugging Proxy等软件允许检查SSL流量而不会在浏览器中引起安全性错误的原因。
#2
17
No, it's not possible to cache https directly. The whole communication between the client and the server is encrypted. A proxy sits between the server and the client, in order to cache it, you need to be able to read it, ie decrypt the encryption.
不,不可能直接缓存https。客户端和服务器之间的整个通信都是加密的。代理位于服务器和客户端之间,为了对其进行缓存,您需要能够读取它,即解密加密。
You can do something to cache it. You basically do the SSL on your proxy, intercepting the SSL sent to the client. Basically the data is encrypted between the client and your proxy, it's decrypted, read and cached, and the data is encrypted and sent on the server. The reply from the server is likewise descrypted, read and encrypted. I'm not sure how you do this on major proxy software (like squid), but it is possible.
你可以做一些事情来缓存它。您基本上在代理上执行SSL,拦截发送到客户端的SSL。基本上,数据在客户端和代理之间进行加密,它被解密,读取和缓存,数据被加密并在服务器上发送。来自服务器的回复同样被解密,读取和加密。我不确定你是如何在主要代理软件(如鱿鱼)上做到这一点,但它是可能的。
The only problem with this approach is that the proxy will have to use a self signed cert to encrypt it to the client. The client will be able to tell that a proxy in the middle has read the data, since the certificate will not be from the original site.
此方法的唯一问题是代理必须使用自签名证书将其加密到客户端。客户端将能够告诉中间的代理已读取数据,因为证书不会来自原始站点。
#3
1
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.
我认为你应该只使用SSL并依赖于进行缓存的HTTP客户端库(Ex:Windows上的WinInet)。很难想象企业级缓存的好处值得在代理上编写自定义安全加密方案或证书乐趣。更糟糕的是,在您提到的加密方案中,在实体主体上执行异步密码听起来像是应用程序服务器端的一个巨大的打击;有一个原因是SSL使用对称密码来实现连接的实际有效负载。
The application concerned is not a browser app, it's a desktop app pulling data over the internet. What is going to happen is that all instances of the app will be pulling the same piece of at around about the same time. This data needs to be secured, but I'm hoping to increase perf by having some instances of the app get a cached version from the corporate proxy server.
该应用程序不是一个浏览器应用程序,它是一个桌面应用程序通过互联网提取数据。将要发生的是,应用程序的所有实例将在大约同一时间拉动相同的部分。这个数据需要得到保护,但我希望通过让应用程序的某些实例从公司代理服务器获得缓存版本来增加性能。
The data chunks are small, but they may be requested frequently. Essentially all app instances are going to request the same data as each other at the same time.
数据块很小,但可能经常请求它们。基本上所有应用实例都会同时请求相同的数据。
The data/message body on the server side will be pre-encrypted and cached in a distributed in-memory hash-table. Encryption will not be performed on a per-request basis.
服务器端的数据/消息体将被预加密并缓存在分布式内存中散列表中。不会基于每个请求执行加密。
I'm also investigating using a message bus, such as NServiceBus instead.
我也正在调查使用消息总线,例如NServiceBus。
#4
1
Check out www.bluecoat.com is a commercial proxy that in fact CAN do https interception in order to block sites, restrict content, inspect for viruses and cache content (GETs)
查看www.bluecoat.com是一个商业代理,实际上可以执行https拦截以阻止网站,限制内容,检查病毒和缓存内容(GET)
#5
1
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 benefits of enterprise wide caching is worth the pain of writing a custom security encryption scheme or certificate fun on the proxy. Worse, on the encryption scheme you mention, doing asymmetric 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.
我认为你应该只使用SSL并依赖于进行缓存的HTTP客户端库(Ex:Windows上的WinInet)。很难想象企业级缓存的好处值得在代理上编写自定义安全加密方案或证书乐趣。更糟糕的是,在您提到的加密方案中,在实体主体上执行非对称密码听起来像是应用程序服务器端的巨大冲击;有一个原因是SSL使用对称密码来实现连接的实际有效负载。
#6
0
How about setting up a server cache on the application server behind the component that encrypts https responses? This can be useful if you have a reverse-proxy setup.
如何在加密https响应的组件后面的应用程序服务器上设置服务器缓存?如果您具有反向代理设置,这将非常有用。
I am thinking of something like this:
我在考虑这样的事情:
application server <---> Squid or Varnish (cache) <---> Apache (performs SSL encryption)