Slashdot Mirror
Mozilla SSL Policy Considered Bad For the Web
Chandon Seldon writes "The issue of digital certificates for SSL and the policies surrounding them comes up repeatedly. I've written an article criticizing the behavior in Firefox 3, which includes a serious comparison of the current Mozilla policy — restricting encrypted HTTP to paying customers — to a violation of net neutrality."
I think it is. Half of SSL is about encrypting a connection, the other half is about knowing whether you can trust the other side. What the article suggests (that SSL connections when the other side uses a self-signed certificate should give no warning) would completely destroy security of the Internet.
I've successfully bought SSL certificates for companies that I had little or no verifiable connection with, from authorities that are trusted by all major browsers. Now, I obtained these with full permission of the companies in question, as a contractor, but as far as the authority was concerned, I was Joe Bloggs.
Same exact experience here. And the thing is that they don't even bother calling anyone to verify anything. I've even used my own credit card to buy certificates.
My blog
If the purpose of the Firehose is to vet articles, it's not doing a good job.
I don't think the purpose of Firehose is to vet articles. Rather, it's a way for Slashdot to become more Digg-like, and Digg-like content is what we get. Seriously, go back five, even two years ago and try to find front page stories in which some random person writes "I've written a controversial article on X. Click here to see my thoughts". You won't find many, but now you can find them almost daily on Slashdot. And along with the Digg-like content comes the Digg-like users, with all their conspiracy theories, hyperbole, immaturity, and general teenage boy mentalities that has driven away all but said demographic from Digg.
Fortunately, Firehose is only a gateway to the editors, and not a direct route to the front page. Thus, the decline of Slashdot has been more gradual than the decline of Digg. But you'd be hard pressed to find a true geek that isn't longing for the good old days.
And oh yeah, Get Off My Lawn!!
Obviously you don't need encryption very badly if you don't care about man-in-the-middle attacks.
For those sites, buying a certificate is possible, but the costs are high compared to the gains (as this is *only* about protection of the data, not about "being sure this is site XY).
If my data needs encrypted, you'd better be sure as a client I want to know it's going to the right place. As the server, you probably don't care (but you should). You don't want to spend $$ to get a cert with a browser pre-installed CA? Fine, but please provide a way to contact your company through the yellow pages or some other non-website contact info that allows people to call a real person and verify the SSL cert. 99.999% of people won't, but sysadmins will.
I really hate that FF3 behavior. At my job they have a proxy+fw that acts like a man-in-the-middle. It connects to the webs you want to see, and you connect to the proxy.
The outcome is that every dammed web that uses https gives me that f*ing warning with sec_error_unknown_issuer, cos of course the issuer is the proxy at my job, and the web domain does not match the issuer.
I have reduced the number of clicks required to add the exception to just 3 instead of 4 by editing the config file so it pre-loads the certificate when you click on the "add exception" link. But it's still a PITA.
I wouldn't mind if it was the default behavior but you could change the setting to a less paranoid one. But the fact there's no way to override this setting makes me angry. I want to be able to decide what do I want to trust or not.
I think you point out clearly the point. Ideally, every webserver should be providing SSL access, but it's certainly not necessary for every one of them to buy a certificate. Most of the time, an ssh-style system of simply accepting the first presented certificate and caching the server's public key is sufficient.
I would suggest that a browser not display the warning you are showing always, but only if the user is being prompted for data. That, or we need to make the three levels of security more clear to the end user. However, I'm not a big fan of putting more requirements on the user.
In my opinion, the problem is the strict hierarchical nature of the SSL certificate system. It needs to make use of existing information contained in social networks. I think some of the information Google holds could be of great use here.
No: if you train your users to ignore "[this certificate isn't signed by a know authority]" warnings, then you makes them substantially MORE vulnerable to man-in-the-middle attacks and, indeed, increases their susceptibility to phishing across the board.
As a web admin you will of course also have to maintain the certificate store, but that may be very easy if you only have a handful of clients. And if you have a handful of clients you may install the root certificate in a controlled situation on the clients, so not even there you have a big problem with insecurity.
didn't you just defeat your own protest to this 'feature?' If you're going to install the cert/root on your clients, then they won't encounter this message, and there's no problem.
Where i DO see a problem is making it very very cheap and and easy for people to register believable certs for
cittibank.com
citibnak.com
citybank.com
citibanc.com
Cost of entry keeps attacks like these targeted, removing that would open things up immeasurably... or do you think the phishing problem is overblown and just a commercial stunt too?
-- D-23994, Muff#2613