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

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)? 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?

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). That is, unless they have access to the private key  
of the targeted server.

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 .

>    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)

> 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.

> 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.

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.


-- 
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
********************************************************************

Received on Saturday, 12 February 2011 17:44:27 UTC