Re: Exposing TLS & Certificate Information in Javascript

Let's put aside the question of which TLS connection to do keying material export from, and focus simply on which certificate would be the most meaningful certificate for the page.

The overall role of the server certificate in TLS is to provide server-to-client authentication.  Nominally, it helps the client answer the question, "who does this content come from?"

As I wrote in my original email, there are two easy canonicalizations: "the first certificate used on the main document", or "the most recent certificate used on the main document".  I argue that "the first certificate used on the main document" provides the clearest simple answer to the question "who does this content come from?", and is also the most meaningful single answer from a security perspective, in that I believe it deals with all of the questions you raise below.

First I'll say why we shouldn't use "the most recent certificate used on the main document".  The main lesson from the TLS renegotiation attack was that, just because the client and server have the same opinion about their current secure connection, it doesn't mean that they have the same opinion on how they got to their current secure connection.  Coming back to HTTPS, an attacker who controls the first part of loading the main document could probably subsequently switch the connection over to the victim server; a client who checks "the most recent certificate used on the main document" wouldn't notice this.

In contrast, "the first certificate used on the main document" prevents this type of attack.  Moreover, "the first certificate used on the main document" provides a meaningful security assertion: whoever owns "the first certificate used on the main document" is in control over what happens on the main document, in the sense that any other security contexts that come up due to that main document only arise because the owner of the first certificate on the main document allowed them to, e.g., by linking to another resource in the main document or participating in a renegotiation on the TLS channel for the main document.  The owner of "the first certificate used on the main document" is the one who controls whether there are any subsequent security context changes.

Let's look at Ryan's non-exhaustive list of potential complications:

> 1) Redirects
>  - eg: "GET /" -> "Location: http://example/bar"
>  Is the SSL/TLS certificate that of the original GET request or of
> the Location?

I don't think this example is relevant, in that the redirected location is http not https.  So I would not expect the resulting document to have any certificate information.  Browsers wouldn't display a lock icon in this case, if I'm not mistaken.

If the redirect was to another https location, then "the first certificate used on the main document" would be the certificate used in the original "GET /" request, as this is the party that originally decided that there should be a redirect.

> 2) Renegotiations
>  - eg: "GET /" -> renegotiation -> headers -> renegotiation -> body
>  The SSL/TLS certificate may have changed at any point in that flow
> (yes, it really *does* happen)
>  For servers that do things like request client certificates after
> the headers, user agents may have persisted the headers from the
> original request, but then tear down the session and establish a new
> one AFTER prompting the user for a client certificate. Both
> certificates apply to the security domain.

The first renegotiation only happened because the owner of "the first certificate used on the main document" allowed it to occur, and subsequently the second renegotiation only happened because the owner of the certificate in the first renegotiation allowed it to occur, and so on.  The chain of trust originates from the owner of "the first certificate used on the main document", so this is the most meaningful certificate.

> 3) Cache Validation
>  - eg: "GET /" -> "304 Not Modified"
>  Is the SSL/TLS certificate that of the original GET request, or that
> of the cached response?

The owner of "the first certificate used on the main document" was the one who decided to say "304 Not Modified", so that's whose opinion the client is trusting right now.

> 4) If you're doing things right, you're *NOT* delivering script inline
> (c.f. CSP), but instead loading it via a script src directive.
>  Is the SSL/TLS certificate that which delivered the script? Or that
> which loaded the "main" content?

The owner of "the first certificate used on the main document" was the one who decided to link to a script in the main document, so again it's "the first certificate used on the main document" that is making the trust decisions.

> 5) Partial content
>  - eg: "GET /" -> "206 Partial Content" -> "GET /" -> "206 Partial Content"
>  Is the SSL/TLS certificate that of the first half of the partial
> content? Or the second half? or the Nth half?

The owner of "the first certificate used on the main document" was the one who decided to return "206 Partial Content" directing the user to make another request, so again it's "the first certificate used on the main document" that is making the trust decisions.

Finally, Harry raised the Channel ID proposal, which I wasn't previously familiar with, and Ryan commented:

> Note that this point has actually been studied quite a bit with
> different browser vendors. There's a reason that proposal's such as
> Channel ID, which Harry mentioned, are much more preferable, in that
> they provide a layer of persistence that transcends the direct
> transport layer.

If we can find a way to solve the problem by adding a JS API but without modifying TLS, wouldn't that be easier to implement and more likely to be adopted than a solution that requires both a new JS API and a modification to TLS?  If we can do this solely in JS, then we only have to modify web browsers, not web servers, because web servers generally already know what their TLS certificate is.

Douglas

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