Blame the browser, not OCSP

Let us talk about OCSP. If you do a little background reading, you’ll discover that almost all implementations do a soft-fail by default, and soft-fail is worse than not having OCSP at all, since it gives a sense of false security. Adam Langley from google discusses the absurdity of soft-fail in this blog post nicely. However, I refuse to accept his claim that CRLset is a good idea and that chrome does it better. Firefox allows me to enable OCSP hard-fail, something that I can not do in Chrome, and hence I abandoned chrome.

What if the browser enabled OCSP by default, and in case of a failure, prompts the user with a warning that says something like “I am not absolutely sure that the connection can be trusted.”, provides a link “More Details” that shows the technical details, and allows the user to choose if he/she wants to proceed. Or highlight the address bar in yellow or something for failed OCSP. Or show a unobtrusive notification .

OCSP is not the magic bullet, agreed. It is a convoluted solution to the revocation problem that demands compromise in one way or other. But if browsers had adopted it in better ways instead of defaulting to soft-fail, the web would have been a much secure place. And I believe compromising a lot of security for little convenience is a bad gamble.

People talk of single point of failure if OCSP hard-fail is enabled, that OCSP servers would be overloaded, and stuff. A compromise between soft-fail and hard-fail as default should work, and I’m sure we can come up with solutions to mitigate the SPOF if enough thought is given to it.

On a related note, I hope OCSP stapling gets more widely adopted. It solves many issues with current implementations, avoids the absurdities of soft-fail and SPOF concerns of hard-fail. Coupling it with a warning notification of the sort discussed above in major browsers will increase its adoption rates.

This post was triggered by a OCSP hard-fail notification for few minutes ago. I get a OCSP failure very very rarely. I suggest you switch to firefox and enable it for better security. To enable OCSP hard-fail on Firefox, go to Preferences > Advanced > Certificates > Validation and tick both the options.

Related articles:


How not to do two factor auth

Two factor authentication – the practice of requiring more than one key to the safe. Every sensible service provides the option these days. But not all do it the proper way.

Rest of the post covers the ground about passwords in general and why two factor auth is a good idea. If you are familiar with the topic, you may find the article boring. You may skip to the last couple paragraphs safely. If you have never heard of two factor auth, continue reading.

Let’s look at the common implementations. We need two keys unlock. The first one’s usually a password.

Lets back up a bit. Why do we need two keys? That’s easy to answer – To make it difficult for a thief to break the lock. Until a few years ago, Passwords alone did okay-ish. But the thieves learned. They used phishing and social engineering to fool users and extract the passwords out of unsuspecting users. Its something similar to showing you a lock that looks like yours. If you fall for the trick and present your key, I make a copy and use it on the real lock.

Since the keys are strings of letters, numbers, and symbols, and people have difficulty remembering lots of them, they usually use the same password everywhere. Or use qwerty or something similar, an easy to remember one. If I have a million locks to pick, and I like to pick as many locks as possible, I can either try all keys on every lock one by one or try the most likely keys on every lock. The second method is easier. Usually by few orders of magnitude.

Now we come to dictionary attacks and brute force attacks. Dictionary attacks use a list of probable passwords and try simple variations of them. Brute force attacks try every possible key on the lock.

And the service providers weren’t idiots. They started rate limiting. You can only try n keys in a minute, or something similar. Trust me when I say that with proper rate limiting in place, brute force and dictionary attacks can take hundreds of years.

But wait, there’s an issue we haven’t addredsed yet. What if people use the same password at multiple sites and the other site was somehow compromised? It happens. A lot. So you now need to protect yourself from the idiocy of others. That’s a bit tough.

And then, it dawned on the experts. Passwords are a bad practice. Too late to fix. The idea of passwords became so natural to the average joe that he’d call you crazy if you told him that passwords are bad. A lot of users are, um, let me put it this way. Security-illiterate. Lots of them. You see, the main issue here is the stupid users. Force them to use strong passwords and you see post it notes on desktop with the passwords. You can’t easily educate them either.

So now comes the beautiful idea. What if we don’t just ask for something the user knows (password), but we also ask that they show us something only they can have.* Enter two factor auth.

A one time password sent to your mobile, or requiring a confirmation on your mobile for every login, or requiring you to present a difficult to forge certificate or special hardware generated secret token, lots of possibilities. But not everyone gets it right.

There is a tradeoff between convenience and security. The trick is to find the fine line that is secure enough but not very inconvenient for the user.

Twitter allows you to require confirmation on mobile for every web based login. To break this lock, the attacker needs both your password and your mobile.

But what if your mobile app doesn’t work or you lose your mobile? Allowing a recovery means the recovery path should atleast be as strong as the actual path. Else any sensible attacker choses recovery, the least secure path. It’s a lot of additional work. But not providing a recovery means that users may get locked out of your service.

I’m surprised I wrote such a lengthy article on my mobile. Allow me to wind it up. I’ll revisit the topic later.

You probably guessed it by now. Twitter’s recovery mechanism seems to be prohibitively tough. Submit a support ticket and wait. I never expected twitter to make such a blunder. People do lose mobiles. Give me some sensible recovery mechanism please..

Find below last tweet in the conversation that prompted this article.

P.S: Writing wordpress articles on mobile sucks. A little.

Evolution not presented in strictly chronological order. I tried to simplify things, may have over done it. Comment your views below.