RFE: Support petnames for SSL sites in Firefox

UNCONFIRMED
Unassigned

Status

()

Firefox
Security
--
enhancement
UNCONFIRMED
9 years ago
3 years ago

People

(Reporter: Matej Kovacic, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; sl; rv:1.9.0.10) Gecko/2009042523 Ubuntu/8.10 (intrepid) Firefox/3.0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; sl; rv:1.9.0.10) Gecko/2009042523 Ubuntu/8.10 (intrepid) Firefox/3.0.10


I am writing this proposal as a result of Firefox Slovenia contest on best proposals to improve Firefox.

My proposal is to integrate Pet Name Tool into the browser. Pet Name Tool
(https://addons.mozilla.org/en-US/firefox/addon/957) is an addon, which "remembers" hash value of SSL certificate on https web pages.

When user comes to SSL protected website for the first time, the window of Pet Name Tools says the webpage is unknown. Then user can enter the name of the site. When user logs into this SSL page next time, Pet Name Tool checks if SSL certificate is the same as it was previous time. If it is so, Pet Name Tool window is green, if not, Pet Name Tool window is red.

In that way, Pet Name Tool makes phishing attacks more difficult. It is important to know, that phishing attacks could not be executed only by self-signed SSL certificates, but also with very sophisticated man-in-the-middle-attack.

The key problem is that man-in-the-middle attacks could be performed by valid (!) signed SSL certificates.

In december 2008 a group of researches showed how to create rogue CA ceertificate. Details are here: http://www.phreedom.org/research/rogue-ca/

This problem is related to the collision in MD5 (details from 2005 here: http://th.informatik.uni-mannheim.de/People/lucks/HashCollisions/rump_ec05.pdf), 

It is important to know, that there are also signs that SHA-1 has similar problems (details here: http://lukenotricks.blogspot.com/2009/05/cost-of-sha-1-collisions-reduced-to-252.html).


Unfortunately, the problem of "valid signed" rogue certificates is not only collisions problem. As it has been found in 2008, some "trusted" Certificate Authorities have special offer. They issue temporary (90-days) free certificates without verification checks done. Details here:
https://blog.startcom.org/?p=145
http://jooray.soup.io/post/10105517/State-of-art-certificates-Whom-do-you

I must say I tried this and get valid SSL certificate for some random website even when I did not entered valid e-mail address.

That means that someone can just get free 90-day SSL certificate for ANY site, which will be signed by "trusted" CA. And the problem is not only Comodo, problem could be any CA company. Maybe they have bad security, maybe there are insiders from some criminal organisation or secret service. Or maybe some criminal organisation (or secret service) establish their own CA company and issue false cetificates for their own purposes.

So it is obvious that the validity of signature of "trusted" CA is not the ultimate proof that site is valid.

BTW: it is also important to know that some newer firewalls and network appliances offer so called UTM (unified threat management). This basically means that they are doing man-in-the-middle on encrypted connections. They are doing this in order to get access to encrypted traffic (mail, web) to check it for viruses or malware. This is illegal in many countries, but it is to expect that this techology of sophisticated MITM attacks will became mainstream in next years. And when that happens, criminals will start using it too.

However, Pet Name Tool has some deficiencies and my proposal is:

- user should have a special container for SSL certificates. Container would collect domain of the SSL website, CA signer and MD5/SHA1 hashes of SSL certificates. When hash changes (for instance certificate was changed for legitimate or illegitimate reason), new hash with new date will be added to the container. So container will have all the history of "user's" SSL certificates.

- user should have the ability for every SSL certificate to mark ("sign") if it is trusted or not. If certificate is trusted, the icon of padlock in the down right corner will be changed in that way, it will have green tick over it. The status of SSL certificate (is it trusted by the user or not) will be also printed in certificate properties window. Website's URL in the URL line will be printed in green color.

- if there will be a change in MD5/SHA1 hash of the SSL certificate, Firefox should notify user with warning. The icon of padlock in the down right corner will be crossed with red x and URL will be printed in red until user will mark that he or she trust new, changed SSL.

I believe this new function of Firefox will decrease a number of possibilities of phisnihg attacks, and Firefox will became even more safe browser. There is also an option to have a common database of trusted hashes for biggest websites like PayPal, GMail, etc., which will be automatically updated.

And of course, something like that should also be integrated into Thunderbird.

Reproducible: Always
Updating the summary a bit.  I thought we already had a bug on file for this, but I can't find it at the moment.
Summary: A proposal for security enhachement of SSL sessions to prevent phishing attacks → RFE: Support petnames for SSL sites in Firefox

Comment 2

9 years ago
Unfortunately I believe that this tool would result in the same behavior as with SSH keys. No one ever contacts the server admin (or site operator for that matter) if he replaced the keys. The user will click through the warning as with any other one, thinking the site updated the certificate.

As such I believe that efforts should be made (and actually are made) at the CAs to prevent occurrence of mentioned failures from above.
(Reporter)

Comment 3

9 years ago
There are many SSL webpages, which I do not care about security. But there are few which are very important for me. Like PayPal, GMail and my local webmail provider.

With PayPal and GMail there could be a solution with a commond database of SSL hashes.

For a "local pages" this option will not be activated, until user will explicitely mark that SSL cert is trusted. From that point, hashes will be "monitores" and warrning issued if they change.

Of course, this is not the ultimate solution, but it is a tool for a conscious user to have an option to be protected.

But if user is stupid enough to enter his credit card number to a site, which clearly says it will be abused - no technical solution can prevent this to be done.

Comment 4

9 years ago
(In reply to comment #3)
> With PayPal and GMail there could be a solution with a commond database of SSL
> hashes.

Don't you think that this is already fairly address with the EV UI?

Comment 5

9 years ago
Kai, is this related to anything you work on?
You need to log in before you can comment on or make changes to this bug.