On Tuesday, April 14, 2015 at 5:39:24 AM UTC-7, Gervase Markham wrote: > On 14/04/15 01:57, northrupt...@gmail.com wrote: > > * Less scary warnings about self-signed certificates (i.e. treat > > HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do > > with HTTPS+selfsigned now); the fact that self-signed HTTPS is > > treated as less secure than HTTP is - to put this as politely and > > gently as possible - a pile of bovine manure > > http://gerv.net/security/self-signed-certs/ , section 3.
That whole article is just additional shovelfuls of bovine manure slopped onto the existing heap. The article assumes that when folks connect to something via SSH and something changes - causing MITM-attack warnings and a refusal to connect - folks default to just removing the existing entry in ~/.ssh/known_hosts without actually questioning anything. This conveniently ignores the fact that - when people do this - it's because they already know there's been a change (usually due to a server replacement); most folks (that I've encountered at least) *will* stop and think before editing their known_hosts if it's an unexpected change. "The first important thing to note about this model is that key changes are an expected part of life." Only if they've been communicated first. In the vast majority of SSH deployments, a host key will exist at least as long as the host does (if not longer). If one is going to criticize SSH's model, one should, you know, actually freaking understand it first. "You can't provide [Joe Public] with a string of hex characters and expect it to read it over the phone to his bank." Sure you can. Joe Public *already* has to do this with social security numbers, credit card numbers, checking/savings account numbers, etc. on a pretty routine basis, whether it's over the phone, over the Internet, by mail, in person, or what have you. What makes an SSH fingerprint any different? The fact that now you have the letters A through F to read? Please. "Everyone can [install a custom root certificate] manually or the IT department can use the Client Customizability Kit (CCK) to make a custom Firefox. " I've used the CCK in the past for Firefox customizations in enterprise settings. It's a royal pain in the ass, and is not nearly as viable a solution as the article suggests (and the alternate suggestion of "oh just use the broken, arbitrarily-trusted CA system for your internal certs!" is a hilarious joke at best; the author of the article would do better as a comedian than as a serious authority when it comes to security best practices). A better solution might be to do this on a client workstation level, but it's still a pain and usually not worth the trouble for smaller enterprises v. just sticking to the self-signed cert. The article, meanwhile, also assumes (in the section before the one you've cited) that the CA system is immune to being compromised while DNS is vulnerable. Anyone with a number of brain cells greater than or equal to one should know better than to take that assumption at face value. > > But also, Firefox is implementing opportunistic encryption, which AIUI > gives you a lot of what you want here. > > Gerv Then that needs to happen first. Otherwise, this whole discussion is moot, since absolutely nobody in their right mind would want to be shoehorned into our current broken CA system without at least *some* alternative. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
