Re: Exposing TLS & Certificate Information in Javascript

See comments below, I have provided other use cases.

Tom's proposal only addresses the main page case, and indeed there must 
be a way to retrieve the tls details of all ressources loaded inside 
this page.

But at least, that's a start of a specification that you requested.

Then it can be considered.

Le 01/02/2013 21:04, Ryan Sleevi a écrit :
> On Fri, Feb 1, 2013 at 11:45 AM, Tom Ritter <tom@ritter.vg> wrote:
>> "Exposing the server certificate (possibly structured, if not we'll
>> need a bullet-proof, signed, X.509 library) and path of the TLS
>> connection as JavaScript objects"
>>
>> This one was mine.  The following doesn't meet the bar of "concrete,
>> well-specified proposal" but it might be the beginning of one.
>>
>> Use Cases
>>
>> 1. A large site that is commonly proxies by corporate and malicious
>> actors wishes to monitor how common this is done.  They place
>> javascript bindings in their code to view the user's certificate and
>> report the observed value.
>> Note this use case has already been performed by Facebook, who had to
>> resort to Flash to do so, because javascript did not provide the
>> functionality.
> Use report-uri with HPKP, in report-only mode, as described in
> http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04

>
>> 2. A large site wishes to detect advanced state actors who may perform
>> sophisticated SSL Man in the Middle.  Although it is possible for an
>> attacker to detect and negate the javascript checks, powerful
>> javascript obfuscation techniques can be used to make this extremely
>> difficult.
> HTTP Public Key Pinning addresses this

Without any powerfull means, it's quite trivial to hide the check.

>
>> Note that this use case fits well with Gmail, who has gone to great
>> lengths to detect certificate attacks in Chrome, and has the necessary
>> javascript infrastructure in place to defend against sophisticated
>> replacement attacks.
>> 3. A large organisation wishes to implement SSL pinning, but is unsure
>> of all the SSL certificates in use by the different teams of the
>> organisation.  They create a javascript include that reviews the
>> certificate chain, and reports it to a central server, and include it
>> in a central framework.
> HTTP Public Key Pinning, in report-only mode, addresses this -
> http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04
>
>> 4. A user wants to write a certificate monitoring extension for Google
>> Chrome, which does not expose the certificate information via any
>> extension APIs.  If the bindings are in javascript, such an extension
>> can be written.  *Note: I'm not 100% sure about the Chrome extension
>> API, but...
> For reasons I will explain below, this does not really fit.
>
>> 5. A user wants to write a certificate reporting bookmarklet that does
>> not require any browser extension to be installed.  They write a
>> concise string of code that will upload the certificate chain for the
>> website to a central monitoring service.
> Bookmarklet support is largely being removed, rather than planned for long term.
>
>> 6. A large website would like to determine how common it is for
>> network issues to downgrade TLS connections.  They detect the TLS
>> version negotiated with the client, and confirm the certificate used
>> so that the connection is with the site and not a proxy, and report
>> back to the server.
>>
>> Specification
>>
>> This is definitely not the correct syntax, but for now I think it gets
>> the point across:
>>
>> 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,
>>          ...
>>          ]
>>      },
>>
>>      clientcertificate = [
>>          CERTIFICATEOBJECT,
>>          ...
>>          ] || null
>> } //End window.location.tls
>>
>>
>>
>> CERTIFICATEOBJECT = {
>>      pem = '...', //A PEM Encoded version of the certificate
>>
>>      fingerprint : {
>>          'sha1' : UInt8Array, //SHA1 is a MUST to implement
>>          'sha256' : UInt8Array //SHA256 is a SHOULD to implement
>>          },
>>
>>      serial : UInt8Array,
>>
>>      version : Uint8,
>>
>>      signature : {
>>          algorithm : 'shaWithRSAEncryption', //human readable string
>>          algorithmid : '1.2.840.113549.1.1.5', //NUMERIC ID (See Below)
>>          value : UInt8Array //the actual signature
>>      }
>>
>>      issuer: FIELDBAG, //See Below
>>
>>      validity : {
>>          notBefore : date,
>>          notafter : date
>>          },
>>
>>      subject : FIELDBAG, //See Below
>>
>>      spki : {
>>          algorithm : 'rsaEncryption',
>>          algorithmid : '1.2.840.113549.1.1.1', //NUMERIC ID
>>          raw : UInt8Array //The raw SPKI from the certificate
>>          //Each defined type will have the individual components
>>          //   pulled out, e.g. for RSA
>>          e : UInt8Array,
>>          n : UInt8Array
>>          //Another idea to use JOSE here...
>>          },
>>
>>      extensions = {
>>          //If an extension appears in the Known Extensions Registry,
>>          //  the extension MUST be exposed as a structured piece of data
>>          //  to be defined for each of the Known Extensions, and
>>          //  indexed by a NAME
>>          //  Example: For Extensions that behave as Subject or Issuer,
>>          //    use a FIELDBAG (see below)
>>
>>          //Extensions not in the Known Extensions list MAY be exposed as
>>          //  a structured piece of data that is indexed by a NAME
>>
>>          //All Extensions, including extensions not in the Known Extensions
>>          //  Registry are indexed by a NUMERIC ID and exposed as a UInt8Array
>>          //  of their value
>>          },
>> } //End CERTIFICATEOBJECT
>>
>>
>>
>> NAME is defined as an ASCII string containing letters, numbers and punctuation
>> NUMERIC ID is defined as an ASCII string consisting of a series of
>> numbers with periods, but no other characters
>> //Two of Many Open Questions: Is there an efficient way to tell if a string is a
>> //  NAME or NUMERIC ID?  There is no Extension identified solely by a
>> NUMERIC ID correct?
>>
>> Examples of Extensions in the 'Known Extensions Registry'
>>   - Enhanced Key Usage
>>   - Subject Alternate Name
>>   - Name Constraints
>>   - Basic Constraints
>>
>>
>>
>> FIELDBAG
>>   - FieldBag.toString() returns the entire contents, e.g.
>> "E=webmaster@ritter.vg,CN=www.ritter.vg,C=US,Description=Rk4N5yzvvg52R4f4"
>>   - But is also accessible as a hash, e.g.
>> window.location.tls.certificates[0]['Subject']['E'] ==
>> 'webmaster@ritter.vg'
>>
>
> 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.

> For any content being displayed on the page, there is no such notion
> as "A" TLS connection:

There is, for the page itself.

> 1) Sub-resources may have been loaded from a cache, with the cache
> entry being created at some point in the past over a TLS connection.
> 2) Sub-resources may have been loaded statically (eg: via <img src,
> <script src>) from some alternative origin
> 3) Sub-resources may have been loaded dynamically (eg: via i=new
> HTMLImage(); i.src=..) from some alternative origin
> 4) Multiple connections may have been employed to fetch the resources
> associated with an origin. These sessions may
>    a) Have established multiple TLS session identifiers (through the
> racing of multiple TCP connections)
>    b) Performed such actions as TLS renegotiation [as commonly used for
> client cert auth]
>
> In light of this, the model even for 'detecting malfeasance' falls
> flat on its face, in that unless every resource load was available to
> the page, apriori, the attacker could always inject their hostile JS
> and just wrap the window.location.tls object to lie. No amount of
> obfuscation is going to save you from harnessing the JS DOM.

No, you can not attack window.location. That's a kind of defect in fact 
but some DOM properties do not really behave like js's ones.

And anyway, window.location could only be a part of the solution here.

>
> The extension model is the most apropros, because both Firefox and
> Chrome (and perhaps other extension supporting browsers, I don't know
> and can't speak authoritatively) permit extensions to interject
> themselves in the communication flow and review all such resource and
> subresource loads, at all points.
>
> In this model, it's purely a discussion of an extension API - an out
> of scope work item. At best, it might be appropriate in the context of
> the newly-chartered SysApps, but I think we're quite a ways off before
> looking at standardizing ALL extension APIs.
>
> So while I appreciate the use cases, and the proposal, I've hopefully
> demonstrated why these use cases proposed are better, more securely
> addressed by other specifications.

Not really, the complete solution would impact different parts of the 
DOM, but one group has to be the lead, and logically it should be this 
group.

>   Certainly, the notion of TLS
> details is a much more complex notion.
>
> (Note: The closest that's available is the Resource Timing /
> Performance Timing APIs, but those do not correlate to individual
> URIs, AIUI)
>

-- 
jCore
Email :  avitte@jcore.fr
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

Received on Saturday, 2 February 2013 19:02:02 UTC