Re: Exposing TLS & Certificate Information in Javascript

See comments again below.

I am not arguing whether HPKP is good or not, or whether other SSL 
technics are secured or not, I am saying that there are other use cases 
where you might need to use non valid certificates for example, and as 
stated in my previous answer the question is maybe not to know what you 
can do with it but just that there are no reasons why the certificates 
details should not be exposed.

Probably you don't see the point of things never considered by major 
companies, but not only major companies need things.

Le 04/02/2013 02:07, Ryan Sleevi a écrit :
> On Sat, Feb 2, 2013 at 11:04 AM, Aymeric Vitte <vitteaymeric@gmail.com> wrote:
>> 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.
> Respectfully, I disagree, but I suspect a further explanation of HTTP
> public key pinning may best be left for off-list. HPKP is
> significantly more robust in the face of attackers than what you
> request or propose.

As written before, I don't really care in fact for now about this case, 
I should have added "or to detect that it has been removed/modified" but 
I am sure that your MITM will never be able to remove/modify my check 
without me detecting it.

>
>>
>>>> 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.
> 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 unpatched),
> 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).

https://www.ianonym.com ?????
There is no https://www.ianonym.com, only http://www.ianonym.com
...
...
...
But thanks to advise, I just checked and there is indeed a 
https://www.ianonym.com, that's a mistake, it should not be, some old 
stuff still in place, I have to remove that, there is no point for now 
for anonym.com to be https.

> 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.


That's a question of interpretation of "THE(s)" tls connection(s), 
window.location.tls (if ever used) should reflect the details of the 
current domain and be updated accordingly, the mechanism should include 
everything you describe, and the same for subresources, +history, which 
is not easy.


>>
>>> For any content being displayed on the page, there is no such notion
>>> as "A" TLS connection:
>>
>> There is, for the page itself.
> No, there is not, as explained above.
>
>>
>>> 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.
> I think that a use case that relies on 'trusted' code operating in the
> same, potentially compromised context as hostile code, in the name of
> security benefits, would be better discussed in something like
> WebAppSec.
For the complete solution, other groups must be involved, but the start 
is supposed to be here (certificate format and what's required to expose 
it correctly)
>
>>
>>>    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
>>

-- 
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 Monday, 4 February 2013 11:08:43 UTC