Jan Schejbal: > Hi, > the new SSL warning is great for normal users, but really annoying for > professionals. I know how SSL works, and if I decide to connect to a > "untrusted" server, I know what I am doing (some pages that I would > normally use via http work only via https, and they have self-signed > certs). I do not want to go trough half a dozen of dialogs for this. Is > there an easy way to revert to the old dialog, or do I need to create an > extension? > > I want to do single-click "ignore warning, connect insecurely, do not > store certificate" and "trust this cert in the future" (if I connect to > the server via a trusted connection). > > An easy way to "connect insecurely" should be offered to users on the > ssl warning page (the wording should make clear to everybody what this > means). The way its currently done, a server with a self-signed cert > looks WAY more insecure than a server not using ssl at all - although an > attack on the ssl-less server needs only passive sniffing, while the > attack against the self-signed one requires a way more difficult MitM > attack.
I suggest your search https://bugzilla.mozilla.com for various postings about this subject. > > I have a few more suggestions that could maybe put into an extension > ("paranoid ssl" or so) - tell me if some of this already exists: > - put the debian blacklist into firefox and show a warning each time a > page uses the cert. Without this, MitM-attacks can use old vulnerable > certificates until they expire (the widely used akamai CDN had one, > valid till October 24) This should go into the main branch of Firefox, > as it is the only way to migitate the great debian openssl f**kup This has been discussed at dev.tech.crypto extensively and some CAs have started to take action actively. > > - allow limiting CA certificates to certifying certain domains (for > example, I want my universities CA to be able to issue valid certs for > subdomains of the university domain and a single other domain ONLY, so > if the CA gets hacked, noone can use its key to create a valid cert for > my bank). This is induced via the name constraint extension in CA certificates. This is up to the issuing CA. > > - allow saving and "locking in" onto a certain cert, to minimize the > impact of CA attacks. Basically I visit a page, verify the cert somehow > (or trust a CA that has signed it) and then select "lock in". If the > cert for that domain changes, I get a warning, regardless if the new > cert is signed by a trusted CA or not (this gets displayed, together > with a note on when the old cert was about to expire and what CA signed > the old and new certs). So if a site suddenly replaces a trusted cert > that was still valid for 9 months by a new one from a different CA, I > will double-check that, while a cert change with the old cert valid for > only 3 more days and the new cert being issued by the same CA will be > fine, so I click "accept and save new cert". Of course, sites with a > saved cert would need to get a special "very trusted" logo (maybe > blue?). Imagine the following scenario: > > A dissident in china wants to get a new Firefox version. He uses a > secure system and is very afraid that the government will replace a > download of a program he wants by a trojan. For this reason, he does his > firefox download via https. The chinese government forced a CA to > cooperate, gets a valid cert for the mozilla web site and puts the > trojan into his download. If you can point to one CA even considering something like this, please forward the name of the CA. However the certificate exceptions dialog does exactly that AFAIK. However you might need to edit the trust flags of the CAs for that. > > - Allow editing of saved certs, for example to limit their validity (if > a cert has alternate allowed domains, to change validity duration etc.) > or to extend it (google.com cert could be extended to be valid for > google.de and www.google.com and www.google.de, reducing the warnings > about wrong domain). I think this has been discussed as an option for CAs with small key sizes, it might be available for regular certificates too. > > - maybe make it easier to add CA certificates. Assume I am at university > connected via a secure LAN that is protected agains ARP spoofing etc. > directly to the servers. I connect, get a warning, and do not click > "accept this servers cert forever" but "accept the CA that issued this > servers cert forever" (and then I limit it to university pages). > For this you should rather import the CA certificate directly if this is what you want to do. > Sincerely, > Jan > Please respect followup-to mozilla.dev.tech.crypto -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
