Tidbits, mind you, not Timbits. Every time I’m dealing with non-Canadians in Canada, and they refer to “donut holes” when they clearly mean “Timbits,” I have a moment where I feel sort of embarrassed for them. Like they just said they were going to nip up the old gorn and scumbles for some hennylummers. Like they are hopelessly antiquated. And then I remember that “Timbit”, like “Kleenex”, “Xerox” and “100% Beef,” is just a corporatism, and truly it is I who should feel ashamed. And I do. On with the show.
SSL Error Pages
Yes, again. But just a quickie. When I land bug 402207 later today, it will slightly change the way adding a security override works. You’ll still have the option to add an exception when you visit a site with unverified security, but whereas recently the dialog that popped up would auto-fetch the certificate for you, it will now pre-populate the url, but make you fetch the certificate yourself.
This isn’t just a stupid attempt to annoy users more, it’s an attempt to make it easier to understand what’s going on. The behaviour of our exception adding is now controlled by a preference named:
browser.ssl_override_behavior
With three values:
- 0 = Don’t pre-populate the site URL or pre-fetch the certificate
- 1 = Pre-populate the URL, but don’t pre-fetch the certificate (New default)
- 2 = Pre-populate and pre-fetch (Old default)
Doing this means that the dialog has less text when users first see it, meaning users might be more inclined to actually read it. It also don’t have an obvious one-click path, the user needs to fetch the certificate (at which point the problems will show up) and then add the exception.
Users who want to fast track the process because they know what they’re doing can just switch that to “2”, and users (or possibly IT departments deploying Firefox internally) might also choose to set it to 0 to compel more user interaction before trust is given to an unverified site.
EV Support
For all the talk about Larry and EV certificates, people might be wondering when they’ll start seeing them. In a funny sort of way, they’re already there – all the code to DO stuff is there, but we don’t yet have any authorities “blessed” as being EV issuers. So that code is idle at the moment.
Kai has now finished up bug 404592 though, which means testers on nightlies can turn on EV trust by setting an environment variable. To see EV treatment on your (post-beta1) nightly, just run with:
NSS_EV_TEST_HACK=USE_PKIX
I won’t go into detail about how to set environment variables, because this only matters in the very short term anyhow, but for those who are fluent in this underworld machination, doing so will prematurely bless the Verisign EV root. This doesn’t mean anything about Mozilla and Verisign and what certs will be trusted in Firefox 3, it’s purely a testing contrivance. Live sites with Verisign EV certs include Paypal and eBay. Once we have at least one EV root in the trusted list, this hack won’t be necessary, and Larry will truly be free to roam.
[Update: It took one minute – sixty terran seconds – for google to index this blog and give me sole possession of the googlerank for ‘hennylummers.’Â Spooky.]
meandering wildly 
…Eye see what you did there.
I like donut holes.
You say that as though any other outcome can occur from the entire EV mess. Firefox will end up blessing the usual suspects as certificate providers, and the world will go on believing that SSL certificate authorities provide some form of authentication, and that these new certificates authenticate them harder.
Hi; whenever I press the TAB key in Firefox 9.0.0.10, then not only the next input field is chosen, but also every next hyperlink in a web page is focussed (unfortunately). I want the TAB key to navigate “through input fields only”. How can users do this?
Ah… that old bug: a page secured by an unknown certificate is considered less secure than a page without a certificate at all.
@Iang – Yup, because a page without a certificate at all can’t MitM an https URL, but a page with an unknown certificate otherwise could. KCM would be better here, obviously, but other than that, suggestions are welcome!
Hi Jonath,
Sure it can, it’s called phishing?! Maybe we are talking about different things here; but the usage of http no-cert pages to pretend to be a https site is well established, and far outweighs the use of HTTPS to MITM other HTTPS sites.
Do you mean that the “using TLS” indicators (padlock, domain, CA, yellow URL) can’t be mimiced by the http no-cert page? I would demur, “absence of indicators” is a poor security tool because the … the user can’t see them to be reminded that they should be there. And, the security context is defined by what the user sees and can be fooled by, not by the security architect defining where the protection stops…
KCM / petnames / secure bookmarks is the best answer I know to MITMs, yes. If not KCM, stick the CA name on the chrome, change the entire look & feel for all cert use (whole thing yellow, or even different colours per CA), and try and move more traffic to TLS via SNI. Yes, I know Firefox has done the latter part, thanks!
@Iang
Yes, we are absolutely in agreement that the vast majority of phishing these days has no need for https at all, since the indicators, or their absence, are not enough on their own to prevent such a thing. But letting self-signed certs through quietly without KCM creates a new attack vector. It lets people MitM https sites without needing victims to fall for a phish – they can type the address in themselves, or use a trusted bookmark, and STILL have a site masquerade at the real one.
When self-signed certs are untrusted by default, this attack is mitigated, since only a CA-signed cert will be taken as valid, but it introduces the unfortunate side effect that sites with the desire to secure communications without establishing an identity have a relatively more painful first experience. KCM makes that better, and I wish we could have gotten there from here in one release, instead of two, but it is still my hope that we will get there.
I’ve heard people complain that KCM still lets a MitM attack through in the case where a) a user types in the full https url, and b) the user has never been the site before. Sure, that’s possible, but I think that trading that off against the convenience of self-signed certs is a lot more palatable than the trade-off originally suggested above, where we just let them all through and cross our fingers that SSL-based MitM attacks stay rare.
Hmmm… well, I see what you are saying, but at a high level there has to be a flaw here somewhere. Consider the open HTTP site. And consider a totally secured site over SSL (plus all the goodies we can throw in). If we call one end “totally insecure” and the other end “totally secure,” and put all the other options in-between, then they must be … somewhere in-between.
Possibly, the assumption that traps us here is that self-signed certs have to be placed in either the “insecure” basket or the “secure” basket. This is a false choice, more reasonably, the self-signed cert lives somewhere in the middle, in its own possibly poor box (better than open HTTP as it defeats all passive listening but not as good as better options, perhaps).
Certainly if you were to treat self-signed certs as “good as CA-signed” that would open a new attack vector. But that’s a failure of assumptions, there are more than 2 choices, as aptly shown by recent green additions.
What would be more of a present, today, argument is that the whole security UI area is so mired in history, polemic, and security failure that adding in a new basket now might just cause more trouble than it’s worth. Then, as perhaps you suggest, KCM is a good way of overcoming the combined weight of history, etc, because it does force an entirely new security UI on the user, which therefore wipes the slate clean of old attack vectors (letting new ones be written on the slate, of course…).
in firefox3 b4pre minefield
if( browser.cache.disk_cache_ssl= true)
“Error code: sec_error_unknown_issuer” pops up, and no way to add it to exception list,
while it’s set to false, all ok.
pls check this bug.
sorry,i checked and find the real reason is
browser.ssl_override_behavior=1 or 2, and using ssl proxy at the same time