[cryptography] yet another certificate MITM attack

Jeffrey Altman jaltman at secure-endpoints.com
Mon Jan 14 21:19:30 EST 2013

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

 Channel Bindings for TLS

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130114/3322432a/attachment.asc>

More information about the cryptography mailing list