481009 - stricter, SSH style security for SSL cookies and/or connections

Status: RESOLVED DUPLICATE of bug 286107

(Firefox :: Security, enhancement)

Description

[scientus]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.6) Gecko/2009020911 Firefox/3.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.6) Gecko/2009020911 Firefox/3.0.6

if somebody controls DNS it is fairily easy to get a SSL cert for a domain that will be trusted by firefox. (https://cert.startcom.org/ for example, for free)

I do not necessarily believe this is broken, and use Perspectives and did not like firefox 3's security dialogs, but I think that it is important to seperate validation of domain name and validation of persona.

Also, although i see it is a problem with phishing, I dont have a huge problem seeing a site that isnt verified, thats what https does all the time, and simply making a https connection does not have to mean i need security. (I think firefox should just remove the padlock, and do a big red slash on https://)

But it is an issue if information is sent to that site, for example cookies.

There could be two levels)

1) if the ssl key changes at all have a warning and/or void cookies. (and never send cookies without some recognition by users) -- This is SSH paranoid mode, which would trigger even when a site updates its time-limited certificate.

2) invalidate cookies and/or warn user if the new certificate deletes or changes the Organization field (O) in the certificate, and/or if the certificate signer is differn't than the last certificate. -- trusted certificates that have something misleading in the O field would be very hard to get, even if DNS was compromised, and a disappearing O field could mean something, as non-identifying certificates (besides domain) are easy to get.

current) what is currently in place: if the certificate is good for the domain, trust it absolutely.


stealing cookies with redirection is not unheard of (http://en.wikipedia.org/wiki/The_Pirate_Bay#Blocking). Of course this fix would not work with http, and it might be better to give the site a cookie than have users log in (although important sites wont trust a cookie over more than one session)

Reproducible: Always

Steps to Reproduce:
Fairily trivial with http
1.Go to a site that sets a cookie
2.have your dns spoofed by any upstream dns provider (or your ip rerouted)
3.have new site get your cookie and appear as the new one.

with https considerably harded as requires controling real DNS
1)set mail server to attackers control
2)validate [e-mail] with StartCom
3)redirect users
4)get cookie, impersonate, etc, even though now the site does not have any Organization validation it may have had, is probably certified by a different certifier, etc.



I think firefox lets users know what is going on really well if you click on the "more information" in the identity box. But: cookies should perhaps not carry over immediately, and have a better way of knowing when signers of certificates, and actual certificates, change.

DNSSEC will largely break the attack vector, but that would still be possibly vulnerable redirections or The Pirate Bay's type.

Comment 2

[scientus]

thx, i did search, but hmm i guess i had "cookie" in my search and nobody had put that so importantly