Re: WebID-ISSUE-28 (bblfish): How does the WebID protocol (foaf+ssl) interact with TLS proxies [User Interface/Browsers]

On 12 Feb 2011, at 18:44, Yngve N. Pettersen (Developer Opera Software ASA) wrote:

> On Sat, 12 Feb 2011 18:00:02 +0100, WebID Incubator Group Issue Tracker <sysbot+tracker@w3.org> wrote:
> 
>> WebID-ISSUE-28 (bblfish): How does the WebID protocol (foaf+ssl) interact with TLS proxies [User Interface/Browsers]
>> 
>> http://www.w3.org/2005/Incubator/webid/track/issues/28
>> 
>> Raised by: peter williams
>> On product: User Interface/Browsers
>> 
>> There are a number of issues.
>> 
>> A. User Interface Issues
>> 
>>   1. How do TLS proxies currently alert the user that he is using a proxy.
> 
> Do you mean a normal HTTPS proxy (tunneling CONNECT HTTP request, TLS client-origin end-to-end, works as normal unproxied connection) or a MITM proxy that pretend to be the server (e.g an Antivirus scanner; these might also be configured as a HTTPS proxy)?

Specifically MITM proxies, as you correctly guessed.

CONNECT proxies don't seem to have security issues from the end users point of view. But there could be an interesting thing to look at: could an employee connect to a CONNECT proxy using WebID to authentify himself, so that people with the right clearance (managers that need a laptop for example) can use the CONNECT end point? My guess is that if you have a laptop then you may as well be able to CONNECT, because you could walk out later with a few GB of encrypted information on your laptop anyway.

> Or some other type of proxy, e.g one that work on the https://proxy/https://www.example.com/path principle used by many VPNs?

If you have a pointer to these types of proxies what their use is and how they work, that could be useful background knowledge.

> Based on context, it sounds to me like a MITM proxy is meant, and AFAIK they do not currently inform the user that he is being proxied, although by necessity they have to use a different CA in order to pretend to be the intended origin host (SSL site), and this would either trigger a certificate warning or require the CA Root to be installed, and it would be visible in the certificate details (and might be considered "alerting" the interested user).

Ok. So companies forcing their users to proxy this way, could end up having real issues with the traffic behind the proxy being proxied by an Evil proxy, and the end user would not know any better, since the important information would not be visible in the URL bar for him to make a decision.

Users whose companies do this should certainly not be using their computer for private business, as the company could see their bank transactions for example.

But as you point out further down, companies that do this have access to the user's computer on which they install the proxy CA where it can pretend it is a root CA. If they can do this, then they can probably also install a browser extension, that would on receiving a message ( a header signed by the proxy perhaps ) be able to pop the right signals in the URL bar, so that the user can be confident he is connected to the right web site.

> That is, unless they have access to the private key of the targeted server.

(yes, we should discount that)

> Related: At the IETF meeting in Maastrict (July 2010) there was a presentation at the SAAG meeting about a method to allow enterprise scanning of encrypted traffic by scanners along the network. http://www.ietf.org/proceedings/78/slides/saag-2.pdf .

Is there some text to go with the slides? I can kind of see what is going on there.

> 
>>   2. How should the proxy alert the user that he is being proxied
> 
> Assuming MITM proxy: Good question. HTTP wise there might be the Warning headers, which the user agent can act on. I am also aware of a specific class of certificates call Proxy certificates, which I am not sure is relevant for this case, identified by an extension IIRC, but at the very least Opera is not supporting this at the moment (the relevant code is disabled)

It would be interesting to learn more about what Proxy certificates are.

> 
>> B. Client Cert Requests
>> 
>>   How do requests for client certs work through a proxied SSL connection? Can they?
> 
> Assuming MITM proxy: They can't. Period. (Unless the client certificate and the private key is hosted on the proxy and it is managing the certificate, sort of like HushMail).
> 
> 
> Client Certificate Verify messages consist of a hash derived from the SSL/TLS handshake messages in the connection being established, signed by the client certificate's private key. With a MITM proxy the verify message will only be seen by the MITM, not the origin, and the MITM can't forward the signature to the origin since it would be negotiating a different session for which the signature would not verify.

Ok, that makes sense.

I can think of a solution here that can make WebIDs work for companies with a setup like this:

	The proxy when asked for a client certificate by the server the employee is trying to connect to could just make a similar request to the employee's browser. On receiving this the browser would ask the employee to select the probably unique certificate he has. Clearly the only thing that would make sense to use here would be the employee's company WebID. Here it is quite conceivable that the MITM proxy could have access to the user's private key, or even more simply that the proxy could create himself a public/private key pair and put the public key on the Employee's WebID Profile. The company would need to seriously trust the proxy software and maintainers of course.

> 
> 
>> C. Technical
>> 
>>    How do TLS web proxies work? Which RFC are they based on?
>>    How does it compare to tunnelling?
> 
> Assuming MITM proxy: They have to act like a normal TLS server, present a certificate that the client will accept, including a matching hostname for the origin server it is pretending to be. Normally these are generated on the fly by the proxy, signed by a local CA Root installed in the client. The MITM will usually process each HTTP request and response itself before passing it along to the intended recipient, perhaps modifying them before passing it on.

great explanation, thanks. This makes it much more understandable.
Also a good reason not to allow "friends" to use your browser, and why you should give them a special account on your computer.

> Tunneling (HTTP CONNECT request) works just like a router, passing packets back and forth after it have established the connection, and does not perform any inspection or modification of the traffic.
> 
>> D. Security/Trust
>> 
>>    How do web proxies work without completely destroying the purpose of SSL/TLS
> 
> 
> Assuming MITM proxy: They have to get their own Root installed in every client in order to avoid warnings being presented to the user.

Thanks a lot for those very clear and helpful answers.

Henry Story


> 
> Sincerely,
> Yngve N. Pettersen
> ********************************************************************
> Senior Developer		     Email: yngve@opera.com
> Opera Software ASA                   http://www.opera.com/
> Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
> ********************************************************************
> 

Social Web Architect
http://bblfish.net/

Received on Saturday, 12 February 2011 18:44:11 UTC