Slashdot Mirror
Firefox SSL-Certificate Debate Rages On
BobB-nw points out the ever more raucous debate over the way Firefox 3 handles self-signed certificates. The scary browser warnings have affected a number of legitimate sites (such as Google AdWords and LinkedIn) that didn't renew certs in time. Lauren Weinstein loudly called attention to the problem early in July. "If you visit a website with either an expired or a self-signed SSL certificate, Firefox 3 will not show that page at all. Instead it will display an error message... To get past this error page, users have to go through four different steps before they can access the website, which from a usability standpoint is far from ideal. This way of handling websites with expired or self-signed SSL certificates is bound to scare away a lot of inexperienced users, no matter how legitimate the website is."
With all the sites out there just looking to steal information from you, and to introduce Cross-Site scripting elements, this is a good idea. I want my browser to warn me when I'm going into uncertain territory. And if a website owner screwed up and did not renew their certs--to hell with them. We're supposed to accept a security risk because they couldn't get off their asses as renew? I don't think so.
Obviously, self signing is meaningless for anonymous strangers. It works just fine for you and your friends/colleagues, but not for anyone outside your immediately trusted group.
What are the free alternatives to VeriSign's hefty fees? Some kind of community effort to create trust, much like PGP key signing seems like it would be a good solution.
Besides being expensive, it looks like any shmo can register with verisign and then conduct all sorts of questionable practices behind their cert. It doesn't look like there's any sort of vetting in the process. I didn't complete the signup process, but it looked like once they had my money, they'd send me a certificate. While the connection is secure, that doesn't tell me a darn thing about what they are going to do with my data, or weather or not they're going to try something malicious.
This one's tricky. You have to use imaginary numbers, like eleventeen... --Hobbes
Because not all of these sites are questionable...
All it does is force these sites to buy certificates from the existing ssl certificate cartel.
Your site isn't questionable, but the business or sysadmin behind it IS. I'm sorry, but when you find you want/need to run SSL encryption, an SSL cert is around $150/year. Not exactly extortion when you consider all the other expenses to run a website (hardware, OS licenses, bandwith).
And some of us WANT to be warned when we're dealing with a cheap-ass website whose people don't have their shit together. To me, a website who has let their certificate expire or is too cheap to spend $10 a year to get a real certificate is not a website that I want to be doing business with in the first place.
SJW: Someone who has run out of real oppression, and has to fake it.
Why are we being told that we must get permission from a "trusted" authority in order to "legitimately" use encryption?
Because a certificate signed by a trusted authority is the only way to eliminate spoofing and man-in-the-middle attacks, such as those that are possible with a DNS exploit, or setting up an open wireless network and setting the SSID to "linksys".
I know of a company that sells caching proxy servers that support HTTPS; their clients use them on corporate LANs and they can see the contents of encrypted HTTPS sessions. This lets them do things like scan outgoing messages for sensitive information to detect when an employee might be using GMail to e-mail confidential documents to someone, even though the connection is encrypted. What makes this possible is, the client's IT department configures everyone's browsers to accept this company's own fake CA key, so they can spoof all HTTPS sites with a self-signed certificate. So it only works in a corporate LAN environment - and the only reason it doesn't work everywhere else too is because SSL certs have to be signed by a trusted CA.
The only possible alternative is to do what SSH does: exchange keys on the first connection, and just assume that you're probably on a trusted network the first time you log in. Then you get a security warning if the server's public key changes. Most of the time this is good enough, but when it comes to online banking, I'd rather be sure.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
The right way to handle this sort of thing is to have a real web of trust of people, and then do caching of the fingerprints of the keys. The first part breaks the CA trusted-party monopoly, and the second avoids non-initial untrusted-cert MITM attacks.
For me at least, the ordering of methods of information transmission that I trust is fairly simple
That sending information to slashdot requires a single click, and sending information to my own https servers requires five seems rather silly; I should definetly be warned, but there's no reason to require me to click to pull up a dialog, click to get the certificate, click to accept, then click to dismiss the dialog. A single message with the certificate information as a warning with a display of what this all means and why it may be problematic is good enough.
http://www.donarmstrong.com