Paint me paranoid, but CA-assisted man in the middle attacks is a real source of concern for me. I would absolutely love to have the SSH-style trust model for my HTTPS connections and I will pay good money for an implementation. A simple browser plugin that implements TOFU/POP on top of PKI would be an excellent start.
Just delete your CA list.
Go into your browser's preferences. Find the "security" section. It should have a button to open up the list of trusted certificate authorities.
Delete them all.
Now, every time you connect to a secure page, one of two things will happen:
1. If you've never visited that page before, your browser will prompt you for instructions. Use whatever means you like (second browser, remote server, call them, etc) to verify the server's SSL fingerprint. If it checks out, mark it as valid (aka "add an exception").
2. If you have visited that site before, its exception will already be present in your browser, and it will work like normal.
After a few days of this, you'll see why the SSH model hasn't seen widespread adoption for HTTPS.
There are my own servers and there is the rest of the Internet. I want to use self-signed certs on my servers and I want these to be sticky. If any of these servers would suddenly start presenting different certificates (most notably, signed by a CA that sits on browser's trusted list), I want to know about this lovely fact.
For the rest of the Internet I can live with existing PKI.
> After a few days of this, you'll see why the SSH model hasn't seen widespread adoption for HTTPS
That's not really true. It has simply never been done for browsers, because many people think it's an abomination and, to paraphrase well-known HNers from previous discussions, supposedly useless and little more than obfuscation instead of encryption.
It's not the first time TOFU/POP has been suggested on HN, too. I find it curious this proposal got so many upvotes here today. I don't remember that many people coming to mine and other people's defenses when we suggested the exact same thing a few months back and crypto gurus were rending their hair like we had committed the most stupidly blasphemous act conceivable to modern computer science.
Notably, SSH will not automatically connect. It asks first. That's why it's useful. Additionally, SSH is such a niche tool that its users can be expected to be security-minded -- for example, by checking that the fingerprint matches the expected string instead of just clicking through.
If browsers automatically trusted a page the first time they hit, attackers can just redirect the user to http://paypa1.com/ and feed them a fancy, green-url certificate.
> Notably, SSH will not automatically connect. It asks first. That's why it's useful.
How many sysadmins really do check their newly installed server's fingerprint? They just type "yes" on first connect and grab the server's certificate. I believe very few people actually do manual loopups when SSH pops the first-connection warning.
Most hosting providers will send you cleartext passwords for your server by email. When you log onto that server for the first time, there is no easy way to tell if you're the victim of an elaborate MITM attack. So that's happening right now.
> If browsers automatically trusted a page the first time they hit, attackers can just redirect the user to http://paypa1.com/ and feed them a fancy, green-url certificate.
Indeed they can. Nobody's suggesting otherwise. By the way, I can do that today, by registering a cert for paypa1.com, just to see how many people actually take a second look at the content of the certificate.
It was an old Usenix conference trick --- I think it's Dug Song's, but I'm not really sure --- to snarf people's SSH logins by capitalizing on their lack of interest in those messages. It's a trivial attack.
You are misrepresenting my position and then attacking me for it.
(All bets are off if someone is targeting your organization specifically, of course: they'd presumably have heard about the server changes in advance and take that opportunity to attack. If I considered that a serious concern in my circumstances then I'd ramp up my security level across the board.)
Though I guess DNSSEC puts you back at PKI ...
I can understand why this might be a good feature to have for end-users and internet novices but why isn't there an option to revert it back to the old "yes/no" box instead of having to click 5 times when I know exactly why there is a self-signed certificate in use...
Also, considering this:
> Global PKI, as currently implemented in browsers, does not work.
makes this feature even more dubious and even worse, together with the green SSL indicator it gives a false sense of security.
Yes, that is possibly the single most annoying thing about any piece of software ever written, at least for those of us who develop secured web sites (and therefore self-sign all kinds of stuff before going to production).
It's quite straightforward to do this with openssl.
A good fix but under the light of the looming issues describe in the link above: why invest all that time implementing and then defending this feature in the first place - for a negligible (at best) security benefit?
This doesn't look like a win to me. Browsers are introduced to websites all the time.
To me, this solution looks like "let's accept an ambient loss of ~5-10% of all connections to MITM attacks, because it's politically too hard to configure the PKI-based SSL protocol properly".
I care most about a handful of sites, most of which are controlled either by me or by people I trust. My co-located mail server would be one of these sites.
There. You now have "tofu/pop".
That would - at least to start with - be additional security.
I think the claim is that this is already the case. There are certificate signing certificates in the hands of people who should not have them and there's no accounting of who has them (beyond the government mentioned) or what they're doing with them. I don't think this presentation is suggesting deleting all your installed CAs, just monitoring whether things are changing under you and coordinating those observations with others you trust. The coordination certainly goes beyond on the SSH model.
You can do that now. Note the cert ID first time you login. If it is different the next time you login, then it is a different cert.
This would be an easy browser extension.