Mozilla has released security updates to Firefox 3.5 and 3.6 that include defenses for an old, little-known, but serious security hole: cross-site data theft using CSS. These defenses have a small but significant chance of breaking websites that rely on “quirks mode” rendering and use a server in another DNS domain (e.g. a CDN) for their style sheets.

In this article I’ll describe the attack, what we’re doing about it, how you can ensure that your site will continue to work, and how you can protect your users who have not upgraded their browsers yet.

Continue reading →

I got some great responses to my ideas for SSL errors and I thought I’d make a new post to talk about them, since that post is old enough that you can’t comment on it anymore. I should probably emphasize up front that I’m not on Firefox’s UX team, I don’t know if they’re listening to my suggestions, and anyway they were meant as a starting point rather than completely finished designs.

David Bolton wanted to know why some of the error screens asked the user to visit other sites manually, rather than doing checks behind the scenes. The main reason, honestly, is that that made a good example thing the user could do next. In practice we probably would want to do at least some checks in the background. Right now, another reason would be that error pages do not have “chrome” privileges so they can’t do anything of the sort (this is part of why the certificate error screen pops up a separate dialog box if you say you want to add an exception) but we may be able to get around that in a real implementation.

John Barton, in email, points out that SSL errors often come up in practice because of server-side configuration changes that ought to have been transparent to users, but a sysadmin goofed. I’ve been using the Certificate Patrol extension, which brings up warnings when a site’s cert changes in any way; this reveals that cert handling mistakes happen even on very popular and well-staffed sites (recently, for instance, mail.google.com flipped back and forth between its own cert and the generic *.google.com cert several times in one day). Of course that would have been invisible to most people, but it’s not much harder to make mistakes that do trigger warnings in a stock browser.

My general feeling on that is, yes, it is way too hard to administer an SSL-encrypted web site, and I would wholeheartedly support an initiative to make it easier, especially for sites that carry information of only moderate sensitivity (e.g. the plethora of Bugzilla instances with self-signed certs out there in the wild). I don’t think that should stop us from raising the visibility of SSL administration mistakes, as long as we improve the presentation and advice on those mistakes so we are not just training people to click through the errors.

John also points out that most people won’t have any idea what “Herdict” is or why they are trustworthy. The explicit mention of Herdict was mainly because I was riffing off Boriss’ earlier proposal to use Herdict information to improve page not found errors. Indeed, we should probably put it more like “Other people who try to visit this website get (something) which (is/isn’t) what you got.” We should credit whatever service we use for that information, but it doesn’t have to be as prominent as I made it.

Someone else (whose name I have lost; sorry, whoever you were!) pointed me at the Perspectives extension, which is said to do more or less exactly what I proposed, as far as comparing certificates seen by the user with those seen by “notaries” at other network locations. I like the use of the term “notary” and the proof of concept; unfortunately, Perspectives seems not to be actively maintained at the moment, and doesn’t work with Firefox 3.6. Also, for privacy, we want to make the queries to the notaries as uninformative as possible to an adversary that can observe network traffic. Reusing the same system that is used for “is this site down?” requests would help there. (Ideally, the notaries would also be unable to tell which users are asking what about which sites, but that might not be tractable.)

The Mozilla Corporation’s new(ish) office in downtown Mountain View has all its third-floor conference rooms named after Internet memes, except those that are named after rooms aboard the starship Enterprise. I’d like to share them with you now.

Small conference rooms (memes)

• All your base
• Bike shed (used as a storage area for a while)
• Chuck Norris
• Dancing Baby
• End of the World
• Fail
• Get to da choppa
• Hampster Dance
• Icanhascheezburger
• Jibjab
• Keyboard Cat
• Leeroy Jenkins
• Mullets Galore
• Numa Numa
• Orly
• Peanut butter jelly
• QQ
• Rickroll
• Strong Bad
• Tron Guy
• Ultimate
• Very good, very mighty
• Win
• Xiao Xiao
• Yatta
• Zombocom

Large conference rooms (Star Trek)

• 10 Forward (break room)
• Holodeck
• The Bridge
• Warp core

Right now, when you visit a website that uses encryption in Firefox and there’s anything at all wrong with the encrypted connection, you get this screen:

This is a big block of jargon which doesn’t do anything to tell the user how big the risk actually is, or help them distinguish a minor problem from a major one. If you click on “technical details” you get a little bit more information about what went wrong, but it still doesn’t make any effort to give advice.

The Firefox UI team has been talking about using Herdict or a similar service to improve network error screens, especially the site not found screen. I think we could get a lot of mileage out of that for SSL errors as well. We should also make use of the user’s history with the site, and pay attention to what exactly is wrong with the credential. Here are some examples.

The only problem with self-signed certificates is they haven’t been signed by a trusted third party. The connection is secure, but you might not be talking to who you think you are. In the first section, we emphasize that the concern here is with identity, and we use Herdict information to deduce that this is probably not a hijacked site, because lots of people get the same credential. (“The same credential” means exactly the same, not just some self-signed cert, but we needn’t bother people with that unless they want to see the details.)

In the “What should I do?” section, we give some examples of things that might be unsafe to trust this site with, but we go ahead and let them visit the site, automatically storing the self-signed cert and marking it valid for this site only. We implement bug 251407, so we can promise to notify the user if the site’s credentials change in the future.

I’ve front-loaded the information that used to be in the “technical details” section, so it has been replaced with “Inspect the Credentials”. If you open that area up, it shows the certificate, but in a more user-friendly way than the existing certificate dialog box does. Especially important here is to reveal the interesting parts immediately, highlight suspicious things, and deemphasize the jargon and the long hexadecimal numbers.

“I understand the risks” is still there, but in this case, it’s for people who didn’t read the rest of the page. It’s meant to make people stop, slow down, and reread. If you click on it you get another link to the page.

There are exploits in the wild that take over your WiFi hub, or your cable modem. Once they’ve done that, they are in a position to tamper with all your Internet traffic. I ran into one of these for reals last week; I was in a café and getting certificate errors on every secure site I tried to visit, including Mozilla’s mail server. (The theory is that you’ll just click through the error messages because you want to get your email, or whatever; one of the staff at the café did just that when I complained.) Here’s where Herdict could really come in handy: if you are getting certificate errors but nobody else is, we can deduce a problem near your computer.

Again, the first section tries to be clear and specific about the problem: we suspect that someone is tampering with your Internet connection, and here is why. The second section underlines how big a deal this is: “Do not log into any site or buy anything online.” It then suggests a test: visit another secure website and see if the problem persists. This scenario should put the whole browser into a paranoid mode, where it will not load saved passwords and continues to try to work out whether there’s something wrong with the local router. Ultimately, we should advise people in this boat to factory-reset their WiFi hub and/or contact their ISP for help, but we should take care to be certain in our diagnosis first.

In this scenario, the “I understand the risks” section gives you access to the certificate-exception dialogs, as it does now.

Finally, here’s what it looks like in the comparatively rare scenario that SSL certificates were originally intended to defend against: the server has been hijacked (but the attackers do not have access to the cert). We can tell from browser history that the cert has changed, and we can tell from Herdict that it has changed for everyone. We tell the user not to visit this website, and again, suggest trying another secure site. (We need to take care to distinguish this case from an expired or legitimately changed cert.)