Re: Exposing TLS & Certificate Information in Javascript

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

Received on Thursday, 30 May 2013 02:10:25 UTC