On Tue, Apr 14, 2015 at 5:59 PM, <northrupthebandg...@gmail.com> wrote:
> 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. > OE shipped in Firefox 37. It's currently turned off pending a bugfix, but it will be back soon. --Richard > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
