Re: Exposing TLS & Certificate Information in Javascript

On May 29, 2013 7:10 PM, "Douglas Stebila" <stebila@qut.edu.au> wrote:
>
> On 2013/05/30, at 01:33, Harry Halpin wrote:
>
> > On 05/29/2013 07:17 AM, Douglas Stebila wrote:
> >> We have been doing some research on building application-level
cryptography on TLS connections.  In one of our recent projects, we wanted
to cryptographically bind from the application layer to the TLS connection.
 There are several ways of theoretically doing so, but the seemingly
simplest would be to get (the hash of) the server's X.509 certificate from
the TLS connection (this is one of the mechanisms specified in RFC 5929,
TLS channel binding).  In our application, only the Firefox extension API
allowed us to access that information (via XPCOM).  It would be nice to
have a standardized way of doing this, and it seems like this may fall
under the category of secondary features in the Web Cryptography API
charter.
> >
> > First, I think the Web Crypto API will not include TLS info at this
> > stage unless use-cases are exceedingly convincing and can convince the
> > WG. Can you add details about your interesting use-cases?
>
> Sure.
>
> In our application, we wanted to implement a cryptographically secure
password authentication protocol at the application layer.
>
> You might be familiar with e.g. the Secure Remote Password (SRP)
protocol, which allows two parties to demonstrate to each other that they
know a low-entropy password without revealing any information about the
password, and which is secure against offline dictionary attacks.  These
type of protocols are password-authenticated key exchange (PAKE) protocols,
and typically also output a session key.  A TLS-SRP ciphersuite has been
standardized but not widely adopted.
>
> We wanted to create an application-layer password authentication protocol
that could be used without modifications to TLS.  With existing Javascript
crypto libraries, we could do all the cryptographic operations we needed to
actually implement the protocol, and thus get secure mutual authentication.
>
> But that alone wouldn't be enough to demonstrate that the TLS channel
over which the application is running wasn't subject to a man-in-the-middle
attack.  A MITM could have simply relayed the password authentication
protocol messages between two TLS connections and it would still succeed.
>
> So we wanted to bind the password authentication protocol to the TLS
channel.  The simplest way of doing so is for the parties in the password
authentication protocol to bind the two protocols together by making the
"password" that they use be the concatenation of their actual password with
some identifying characteristic of the TLS channel.  We could try to bind
using the TLS Finished message or TLS exported keying material, but these
have many of the problems that Ryan has identified and also require access
values from deep in the TLS stack.  Alternatively, we could bind using the
certificate of the TLS server in the connection.  This way, the password
authentication protocol succeeds only if both parties have the same view of
the password and the same view of who the server is in their TLS
connection.  Assuming that the server's private key hasn't been
compromised, this is enough to provide the strong level of security we
wanted for the protocol.  (Note as well that it doesn't depend on a correct
PKI binding between the server's identity (domain name) and public key.)
>
> If you'd like to read more, a preprint of our research paper is available
at http://www.douglas.stebila.ca/research/papers/msd13/.
>
> Douglas

What protection does this actually provide in the event of a MITM? I would
argue none - hence why I am not terribly convinced its worth the effort.

You're relying on JS delivered by an attacker to do the cryptographic
binding to the server's cert. The attacker will simply prompt the user
(...in JS) for their password, then rebind that to the "real" server's
public key.

You get absolutely zero of the security value of channel bindings in that
scheme - because you are forced to trust the attacker.

Solving the "secure delivery of code" is a non-goal of this WG. Trust TLS
(which your model, by design, does not) or use SysApps (as I earlier
suggested) have been the two responses so far for this problem.

Cheers,
Ryan