Re: Exposing TLS & Certificate Information in Javascript

On Wed, May 29, 2013 at 1:50 PM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com> wrote:
> Ryan
> Thank you very much for the list of example issues. Very insightful.
> However, I still have questions. Please see inline.
>
> --Seetharama
>
> On 5/29/13 1:53 PM, "Ryan Sleevi" <sleevi@google.com> wrote:
>
> This is far from an exhaustive list, but is provided as proof.
>
> 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.
>
> 1) Redirects
>   - eg: "GET /" -> "Location: http://example/bar"
>   Is the SSL/TLS certificate that of the original GET request or of
> the Location?
>   Is the SSL/TLS session (eg: for key material export, as raised by
> Tom Ritter) that of the original GET or of the new resource?
>   - Surprise: UA's disagree.
>
> Not sure why UAs disagree – to me it appears that the certificate from
> second GET is what matters, because that is from where I am getting my
> actual content.

That's one opinion.

>
> 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.
>   - Surprise: UA's disagree.
>
> Again, not sure why UAs disagree. Renegotiation is fine, but the body gets
> downloaded after the SECOND renegotiation – which means the latest server
> certificate that is used to download the body is what I am interested in.

That's one opinion.

Another is that given that the headers affect the security state - and
that the initial get request may have included sensitive information
such as cookies, it's more important.

You can of course do renegotiation in the body. I only know of one
server that ever (did) this.

Regardless though, there are differing opinions on this.

>
> 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?
>   - Surprise: UA's disagree.
>
> Not sure I see a distinction – 304 is coming as a response for a GET request
> sent over TLS, and so the 304 response is as reliable as any content.

There's no requirement that the 304's certificate match the original
content's certificate (IF that was even stored in the cache - and
again, UAs disagree).

>
> 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?
>   Is the SSL/TLS session (eg: for key material export) that of the
> script or of the main content?
>
> As I mentioned in my earlier email, I think we are talking about the TLS
> used to download the main content – not the TLS of the script. May be we
> should clarify the requirement as such.

And if the main content was cached (which may not have persisted any
details about the TLS session)? And given that the TLS session of the
script is as important for establishing security boundaries?

>
> 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?
>
> Can we treat this as an exception case and call out that certificate
> information will not be available if the certificate differs across each GET
> request?

Again, these are just a sampling of the problems that are posed - and
for a, respectfully, ambiguous (at best) set of use cases.

You're proposing to redefine UA's network stacks to accomodate a JS
API that, at least at first glance, does little to nothing to actually
provide any security benefit. There's a very high bar to demonstrate
why or how this would be useful, in a way that is consistent with the
*web* security model.

Cheers,
Ryan

Received on Wednesday, 29 May 2013 21:05:54 UTC