Hello there,

  As you already know (:-)) when firefox visits an SSL enabled site and gets a 
certificate that cannot be verified, asks the user about the action it should 
take. The current actions are: Accept Permanentely (#1), Accept for Session 
(#2), Don't Accept (#3), having #2 as the preselected option.

  I believe that this (option #2) is the most insecure of all. Let me explain 
my thoughts:

* If the user reject the certificate then there can be no harm

* If the user accepts the certificate permanently:
  * The certificate may be valid and thus he will be protected for all future 
sessions, because a fake certificate will not match the already accepted one.
  * The certificate may be fake (man in the middle). If it is fake, they user 
most probably will find it out when he will try to visit the site at another 
moment in the future, when there will be no mitm attack taking place. Firefox 
will warn then about the wrong certificate and the user will be alerted.

* If the user accepts the certificate permanently is like drawing a lot. A 
user that visits an https-powered webmail site 4-10 times a day just 
increases the possibility of a mitm attack to succeed.

  Of course you'd ask 'who visits a site so often and does not accept the 
certificate permanently'. Well, my experience shows that there are many such 
people (I work as a sysadmin in a University).

  So I suggest (and kindly ask) you to:

a) Change the default option to #1 or #3
b) Discourage people from selecting #2 (even display a warning box)
c) Perhaps implement an aging (cache expiring) method to delete very old 
certificate and possibly add an option 'remember for 1 year', where each new 
visit will reset the countdown timer.

  All of these could be accompanied with a more alerting dialog box to be 
shown when there is a certificate mismatch.

Best regards,
Harhalakis Stefanos

p.s. I'm subscribed to the list but please CC me
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security

Reply via email to