728650 - There is no DOM API to access SSL certificates chain details

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Alex Syrnikov]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Build ID: 20120215223356

Steps to reproduce:

I have googled for JavaScript access to SSL ceritficates chain details.


Actual results:

Nothing found


Expected results:

I want Firefox JavaScript provide access to current HTTPS session information. So I can get this information, submit via AJAX on original server and get result from server side script. Does my session sertifocate chain match oroginal server SSL chain. This will help to detect man in the middle attack and inform clients in case of attack. Also this allow to collect Root CA (such as TrustWave) incorrectly using their certificates (selliing it to third party).

Comment 1

[Mardeg]

While waiting for a resolution to this bug, websites can suggest that users install
https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/ for informing them in case of attack.

It's possible giving sites access to this info in unprivileged javascript (not inside an extension) would allow malicious sites to gain the same info for deceptive purposes.

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Alex Syrnikov from comment #0)
> I want Firefox JavaScript provide access to current HTTPS session
> information. So I can get this information, submit via AJAX on original
> server and get result from server side script. Does my session sertifocate
> chain match oroginal server SSL chain. This will help to detect man in the
> middle attack and inform clients in case of attack. Also this allow to
> collect Root CA (such as TrustWave) incorrectly using their certificates
> (selliing it to third party).

The attacker that is using a fake certificate is likely to also use that fake certificate to remove or modify your script's checks, so in general this technique will not work.

Comment 3

[Igor Bukanov]

(In reply to Brian Smith (:briansmith, was :[e-mail]) from comment #2)
> The attacker that is using a fake certificate is likely to also use that
> fake certificate to remove or modify your script's checks, so in general
> this technique will not work.

Even simplest obfuscator that randomizes its output and that a web site can run periodically makes attacks that patch the code rather hard to perform. Faking certificates is really much simpler. So a website performing a certificate check as a part of a normal page operation in obfuscated code can raise the attack bar sufficiently to make attacks unprofitable.

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Another issue is that the certificate path built by the client is not guaranteed to be the same as the one the server sends. In that case, it would be difficult if not impossible to differentiate between an attack and an equally valid trust chain.

Comment 5

[Igor Bukanov]

(In reply to David Keeler (:keeler) from comment #4)
> Another issue is that the certificate path built by the client is not
> guaranteed to be the same as the one the server sends. In that case, it
> would be difficult if not impossible to differentiate between an attack and
> an equally valid trust chain.

What about a cerificate fingeprint? Is it possible to have a situation when it is different from the one on the server?

Comment 6

[Dana Keeler (she/her) (use needinfo) [:keeler]]

(In reply to Igor Bukanov from comment #5)
> What about a cerificate fingeprint? Is it possible to have a situation when
> it is different from the one on the server?

Probably not, but again, by the reasoning in comment 2, this is unlikely to be useful.

Comment 7

[Igor Bukanov]

(In reply to David Keeler (:keeler) from comment #6)
> (In reply to Igor Bukanov from comment #5)
> > What about a cerificate fingeprint? Is it possible to have a situation when
> > it is different from the one on the server?
> 
> Probably not, but again, by the reasoning in comment 2, this is unlikely to
> be useful.

This is simply not true. Yes, the bad guys can and do inject arbitrary javascript code to perform fraud. However, it is extremely more difficult to develop tools that automatically discover and patch the code performing various JS action in a sufficiently obfuscated JS code than to fake certificates. The automatic tools are necessary as the server can use a randomizing obfuscator and deploy different code for different IP addresses.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.4265&rep=rep1&type=pdf describes what is theoretically possible with obfuscation. Of cause the JS case is not that advanced (yet), but still this is informative.

Comment 8

[Joe Steele]

I notice bug 992096 (Implement Subresource Integrity - https://bugzilla.mozilla.org/show_bug.cgi?id=992096) is getting some love but is subject to the same issues mentioned above. Resolving this bug would be useful for many of the same reasons as resolving bug 992096. And would allow for the entire domain to be validated to some degree (which is not supported by the other spec). Is anyone up for revisiting this bug?

Comment 9

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.