On 1/14/2013 7:39 AM, Harald Hanche-Olsen wrote: > So let me play devil's advocate for a moment: You could say that the > browser has two components: One in the phone and one in a server > somewhere. The two components communicate over a channel provided by > good old https. The phone component sends the request to the server > component, which in turn forwards it to the remote server and then > transforms the response into a more compact form before sending it > back to the phone component. Thus no MITM, just a clever bit of > distributed computing. > > The notion of the user as one end point of the protected channel is > illusory anyway; in reality, it the browser that is the end point.
As far as I am concerned there is no protected channel UNLESS mutual authentication is performed of both the initiator and the acceptor using an authentication mechanism that verifies that each party sees the same endpoints. This requires the use of channel bindings: On the Use of Channel Bindings to Secure Channels https://tools.ietf.org/html/rfc5056 Channel Bindings for TLS https://tools.ietf.org/html/rfc5929 The underlying problem is not that someone decided to setup a https proxy service which is trusted by the browser in the device. The underlying problem is that sending usernames and passwords (or their equivalents) across a channel for which only one endpoint is authenticated is fundamentally flawed. I first implemented TLS channel bindings in 2000 as part of the Telnet Start-TLS option specification which permitted a TLS protected channel to have both endpoints mutually authenticated using either AUTH KRB5 or AUTH SRP. When mutual authentication is used with channel bindings to verify the endpoints belong to the authenticated parties, then it doesn't matter if you use Anon-DH, a shared key cipher, or something dependent upon a certificate. The fact that the browser is the initiator is find provided that the browser combines an authenticator provided by the end user with the TLS channel binding information to permit the accepting service to verify that the authenticator originated at the initiating endpoint. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
