Re: Exposing TLS & Certificate Information in Javascript

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.
>
> Ryan Sleevi kindly pointed out a discussion thread on this mailing list from February 2013 that discusses things related to this issue, where an API exposing a variety of information on the TLS connection was proposed.  The subsequent discussion in the thread pointed out the subtleties of what is "the" TLS connection (http://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Feb/0006.html; portions reproduced below).  I apologize for being late to the discussion and reopening a dormant conversation, but it did not seem to come to a resolution, beyond that there are subtleties.
>
> While it is true that there are subtleties, getting at least some information about the TLS connection would be a very useful thing to have available, and it may be possible to identify a canonical set of TLS parameters.  In fact, browsers effectively do so: when you click on the lock icon, you get a single certificate and a single explanation for the properties of the TLS connection.  I'm not sure which canonicalization browsers use, but two potentially reasonable choices include "the first certificate used on the main document", or "the most recent certificate used on the main document".  Yes, a single snapshot doesn't capture the whole history of the security context, but it does capture the security parameters at that canonical point in time, and that's enough to enable some interesting applications.
>
> In summary: can we have an API that gives the same information about the TLS connection as what would be obtained by clicking on the lock icon in the web browser?
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?

Also, are you aware of the channel-binding work of Dirk Balfanz at Google?

https://tools.ietf.org/html/draft-balfanz-tls-channelid-00

I'd be open to seeing what precisely you think a TLS draft API should 
include. I think you'd have to answer the questions Ryan brings up about 
multiple TLS connections and then decide what how you'd like to see 
either "the first certificate" or "recent certificate" played out given 
at least the example code below. But overall, a real TLS API proposal 
that exposes this kind of info to JS should deal with the hard questions 
Ryan mentions.

>
> Douglas
>
>
>>>>> window.location.tls = {
>>>>>       version = 'SSL 3.0' || 'TLS 1.0' || 'TLS 1.1' || 'TLS 1.2' || '',
>>>>>
>>>>>       //I'm really bad at naming things
>>>>>       flavor = 'PKIX' || 'SRP' || 'PSK' || 'OpenPGP',
>>>>>
>>>>>       ciphersuite = { //From https://www.iana.org/assignments/tls-parameters/tls-parameters.xml
>>>>>           value = UInt8Array, //From the Value column
>>>>>           description = string //From Description Column
>>>>>           //Potentially fill out sub values like "Cipher", "Key Exchange"...
>>>>>       },
>>>>>
>>>>>       //.certificates is an array of Certificate Objects, or an
>>>>>       //  empty array if no certificate is used (HTTP, TLS-PSK, DH-Anon, etc)
>>>>>       //  [0] is the root, and it goes in ascending order to the leaf,
>>>>>       //  based on the path constructed by the browser
>>>>>       certificates = [
>>>>>           CERTIFICATEOBJECT,
>>>>>           ...
>>>>>           ]
>>>>>       },
>>>>>
>>>>>
>>>> The failure of this entire proposal is that it disregards the multi-connection, multi-origin model involved in any origin load.
>>> Yes, except for the main page.
>>
>> No. Even the main page may have had multiple TLS identities involved.
>>
>> 1) It may have originally requested example.com, but may have been redirected (302 to 307) to subdomain.example.com. However, the identity of both is relevant in terms of origin security, since the initial example.com may have been hijacked by an attacker to leverage items such as session pinning or cookie hijacking.
>> 2) If the server is not TLS renegotiation patched (as a disproportionate number of servers unfortunately remain unlatched), then a hostile MITM may interject themselves before initiating a renegotiation. For example, your site  https://www.ianonym.com is vulnerable to this well-known attack (only noticeable after ignoring the certificate mismatch).
>> 3) Even absent hostile intent, a server may be configured to renegotiate the security parameters of the server in such a way that fundamentally alters the connection. This is quite common.
>> 4) In the face of invalid certificates or requests for client certificates, which require user interaction, many user agents will break the TCP connection after a certain amount of time has elapsed, since the active connection is contingent upon user interaction. Thus a logical load may have employed multiple connections.
>
>
>

Received on Wednesday, 29 May 2013 15:33:33 UTC