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

There are lots of ways to address it. The CCV is not limited to what is
asserted (being RSA centric, in its presentation). There are many more
approaches that leverage the properties of non RSA handshake designs.

 

Without overloading folks, there is 50 years of debate on using crypto
handshakes in two competing structures: one terms the trusted relay
structure, the other termed the writer-to-reader structure.

 

Billion dollar organizations with egos the size of the exhaustive
searchspace for theoretical ciphers have argued for 50+ years on the topic.
Makes the various incarnations of the format wars look puny.

 

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

 

 

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