This type of compromised-CA attack is why I never understood why browsers don't use the OpenSSH model: accept and store (prompting for confirmation) the certificate the first time you connect to a site, then throw up enormous red flags if the certificate ever changes.
The Firefox root CA list has dozens and dozens of organizations on it. Could a compromise of any one of them mean that this attack could be repeated?
Because that security model means that a compromised ISP can permanently MITM you the first time you visit a site on any computer for the first time. In exchange for losing the single points of failure, it creates a constant stream of opportunities to break the trust model.
You may think that's a good tradeoff. I don't, but reasonable people can disagree about it. However, it's completely untenable for financial information, because attackers after financial information aren't laser targeted and are perfectly happy with a constant stream of compromised sessions. Remember what TLS was designed for in the first place.
The OpenSSH model implies that you check the fingerprint of the public key before you send encrypted data using that key. That is why SSH shows you the fingerprint of the server key when you first connect, and you have to answer "yes" in order to accept the key and add it to your keyring. You are supposed to have talked to the person managing the system and that person should have given you the fingerprint of the key.
It is virtually impossible for the ISP to intercept and sniff the stream without changing the fingerprint.
"Wrong! Random people will totally verify key fingerprints when they're logging into Google Mail at Starbucks! After all, that's what every sysadmin does with SSH, right!"
I have no idea what you are trying to express here. "Trust On First Use" is a synonym for key continuity. The fact that you have to type "yes" when SSH does it and click a series of buttons when a browser does it doesn't change anything.
I think you think that "Trust On First Use" means "automatically accept keys the first time you hit a site". In fact, that's only true in practice. Presumably everyone's going to get the "Watch Out! This Could Be Iran!" dialog from their browser, too.
There isn't any non-Internet communication channel that users could use to find Google's fingerprint. Google won't give their fingerprints on the phone for billions of web users.
Theoretical models that have no practicality in a given real life context aren't worth discussing as a solution.
normally it just shows you a horizontal bar alerting you when a host's ssl certificate changes, and whether it thinks it was for a good reason like the old cert being near its expiration date.
annoyingly, google has a number of different ssl certificates installed on different servers/load balancers (some wildcard, some not, some signed by different CAs, some signed by google's root) so nearly every time i would use a google service, the add-on would be throwing warnings at me that must be manually clicked to be dismissed. eventually i gave up and stopped using the add-on.
You are absolutely right. Although I think it is undesirable to enable such a feature by default, as a technical user, I badly want it. I want browsers to cache certificate public keys and alert me when they change.
Or just when the host is migrated. This technique "works", I guess, but the false postive rate is staggeringly high. I see these errors daily (generally due to DHCP reuse of my test boxes' addressess). In decades of use, I don't believe I've ever once been MitM'd over ssh.
SSH users understand the issue and are happy to triage a "not in known_hosts" error. The general public won't have a clue.
The Firefox root CA list has dozens and dozens of organizations on it. Could a compromise of any one of them mean that this attack could be repeated?