Re: new version trusted-proxy20 draft

On Mon, Feb 24, 2014 at 11:56:52AM +0100, Mikael Abrahamsson wrote:
> On Mon, 24 Feb 2014, Ilari Liusvaara wrote:
> 
> >5) Regarding to usescases, protocol conforming to principle of
> >least priviledge and accomodiating all or even most of those (goes
> >up to "Tom's Rural broadband" right now) would likely be hideously
> >complicated mess of crypto.
> >
> >6) Because of the last, one is pretty much limited to no trust (CONNECT)
> >or full trust (GET/POST/PUT).
> 
> So I am new to this discussion, but I'll give it a go anyway.
> 
> The "mess of crypto" mentioned above, does that relate to an "onion
> style" kind of crypto, where the web server would first encrypt/sign
> the object with its own cert, and then use another one to send
> traffic to the proxy?

Well, if you just need downstream integerity, one could just put a
random MAC key in, sign that with server's public key and then do
a streaming MAC with given key.

Doing encrypted caching... That would require client and server to
share state.

> I was thinking if it was possible to keep confidentiality of the
> communication between web browser and web server, but still give the
> proxy enough information to do its job which would be caching and/or
> doing content access control.
> 
> I guess the use-cases that are being adressed by this draft are two-fold:
> 
> 1. Proxy that wants to know what URLs are being used so it can
> record/limit access.

Encrypting arbitrary data in upstream direction is doable. Question
is, what can be encrypted without causing smuggling issues.
 
> 2. Proxy that contains malware detection and so on to inspect all
> contents before it's delivered to the end systems.

Such system does not necressarily have to modify upstream/downstream
data, just be able to reject requests.


-Ilari

Received on Monday, 24 February 2014 12:05:50 UTC