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."
wouldn't implementing what the author suggest, defeat the very purpose of having a CA ? SSL is not just for encryption you know. There is a little thing called 'trust' which pays a big part in it too.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
The whole point of SSL is to have some assurance that you are connecting to whom you think you're are connecting to.
While the model of paying a CA to assure your identity is not perfect by any means, ignoring the issue isn't either. Many slashdotters seem to have a hard time getting this.
IMHO, the system in Firefox 3 is superior. While self-signed sites are blocked by default, it is not easier to explicitly trust a self-signed SSL site. In the past, most people would just click past the nag dialog when it popped up.
Conformity is the jailer of freedom and enemy of growth. -JFK
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 encourage all of my users to use Firefox by including it on our PC images, showing them it's cool features, and letting them know about how it's more secure. I've been running into problems with self-signed SSL certificates though.
I run a router/firewall based on the Untangle software, which in turn is a modified Debian/Knoppix setup. It also does VPN, based on the open source openVPN software, and it uses self-signed SSL certificates for it. While I don't mind adding our firewalls to a safe list, my users freak out with all of the warnings and aren't sure what they should do. I've been telling them to use Internet Explorer, but it makes my skin crawl to say it. Hopefully the Mozilla team will reconsider their position to make their software more open-source friendly.
As the article admits, you can import the cert and access any SSL website. It's kinda weird to write an article about using a scary "you are being hacked" warning and then post a scary "firefox 3 doesn't let you use SSL unless you pay" statement.
Yeah this is no good. And its a real shame that it comes from the "good" browser. I'd expect this from safari or IE. All we need is the information about the cert. Let the user decide if he/she is ok with using the site.
Support bacteria, the only culture most people have.
For some small sites, we need to encrypt traffic to protect consumer data from being "spyed on" by misconfigured switches, WLAN eavesdropping, and so on.
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). Based on the certificate IDs/hash it's possible in this environment for anyone to compare whether the certificate is a trustworthy one, or not. The certificate identification is, in this case, possible.
But it's a lot harder to explain why this really, really scary message (it scares the HELL out of customers) appears now and then, when someone moved to a new computer or something.
The old FF2 behaviour was "better" in this respect.
I also see benefits of the efforts made to clarify this encryption/identification stuff for normal users, like the green address bar. That's really a gift, showing the user "everything all-right with your banking application or amazon store".
But this behaviour marking "self-signed" certificates as something über-evil out of the deepest depth of hell, is crossing a line a bit to far, in my opinion.
A short warning with a better explanation, or even a yellow bar - encrypted, but not "that secure" - might have been a better way.
Well, patches welcome, I hope :)
Still better than just praying the 2012-expected Internet Nightmare 9 misteriously replacing the old behaviour with something worse. You know what I'm talking about, are you? ;)
The average user doesn't notice any security feature unless it is in their face.
Given the number of phishing sites out there, it could be argued that every additional slap to the face that a user would have to get through in order to get to a phishing site (known phishing site, self-signed SSL, acknowledge that you are a fucking retard for bypassing the last two warnings, etc.) may be worth it.
Just remember that just because the precepts of net neutrality (all bandwidth is equal) means that we should let a user shoot themselves in the head doesn't mean that we shouldn't at least make a passing effort to put a safety on the gun they are using.
RomSteady - I came, I saw, I tested. GamerTag: RomSteady / http://www.romsteady.net
Is it wrong to have quick and dirty arbitrary secure end to end connections?
In four mouse clicks I've added that site to my exceptions list. It warned me, I read and understood the warning, I acted. I saw the https page and the web site owner didn't have to pay for a certificate.
So, the article is wrong:
"Mozilla Firefox 3 limits usable encrypted (SSL) web sites to those who are willing to pay money to one of their approved digital certificate vendors"
please add 'or click four times to add the site to an exception list'.
This is bullshit.
It's not like Firefox makes it impossible to access a web site with a self signed certificate. It just makes it very obvious that something is wrong with the certificate, and tells the user that he shouldn't trust it to much.
Now, who uses self signed certificates or certificates signed by an internal CA?
* Test environments (not an end user scenario)
* Unprofessional webhosters (good riddance)
* Companies with their own CA (they can preload the certificate)
* Hobbyist systems (they can reconfigure their browser)
In the end, the only ones hurt by this are unprofessional webhosters - and i don't think anyone should care about them.
fta:
"This is really an issue of the basic principles of internet openness. Everyone has equal access to the features of HTTP or SSH, there's no reason why there should be artifical constraints on access to HTTPS. But that's exactly what the Firefox SSL behavior does."
The above statement makes it sound as if SSH and HTTP(s) are related. Quick summary:
http
ssl
https = http + ssl
ftp
ftps = ftp + ssl
ssh/sftp (they stand alone)
I'm not sure what the problem here is - If a website claims that it isn't part of the malware revolution with a self signed certificate, it isn't any more authentic than NOT having one.
The only real use for a self signed certificate is for large institutions that already have the trust of the user (ie: universities) - but you have to assume that they havn't been compromised, because it would be easy to have a second certificate, signed by the owner of the hijacked site.
Anyways, firefox 3 does a great job, and it isn't hard to add an exception - and it isn't annoying like UAE...
Surely this is the same as has been implemented in all browsers since SSL came along? the only real difference here is in how the message to the user is displayed. Previously, a dialog box would have popped up warning the user, and most users would automatically scan for the OK button and click it without giving it further thought, or indeed reading the dialog box.
Because this message appears where the page would normally appear, people seem to be actually taking notice of it. It's not about net neutrality, it's about trust. There are a number of trusted root certificate people out there, and that number is small for a reason. If everybody could create a trustworthy certificate, then what would be the point. It's a shame users have in the past been so useless at exercising judgement in what sites are trustworthy and which aren't.
At least now, they are forced to consider the implications clicking through, and that can only be a good thing.
what do you mean, trust?
An SSL certificate automagically means that it is impossible for the site to be hacker, or some guy internally running away with sensitive data, etc. ?
At best, it will say "Why yes, this -is- the website you are looking for.".. beyond that, there's no more trust than I would give a warezyporn website hosted on a .tk domain.
SSL may not be just for encryption, but perhaps it should be.. or should have been. It should never have served this dual purpose - and the story explains quite nicely -why-.
"we are programmers and developers, and as a community we think this is the right thing to do" - this does NOT fly. public accepts what they like, they refuse what they dont. this is as simple as that, REGARDLESS OF what they accept or refuse may be good, or bad.
it is utterly stupid to go overly jacobin and enforce something on people 'for improving the security on the web', in an open source project that is made by people FOR the people.
a lot of websites, service owners, businesses using vpn and their clients and their users are going to experience hell lot of problems due to this extreme self righteousness forced upon them, if they go for firefox 3.
to be honest, despite im fighting for free and open internet, linux, open source by the means available to me as much as i can, i will be advising friends and clients to stay away from ff3 because of that certificate issue.
Read radical news here
I suppose you could just add an exception for the site you want to access. (Four clicks?) Or your corporate IT people could add their signing certificate to the version of Firefox they distribute.
I don't understand the "antifeature" accusation at all.
>north
You're an immobile computer, remember?
Not so much... You can accept certificate once and for all for a site, it's not that much annoying.
Well, the betta of FF3 was annoying because it wasn't clear how you could accept those certificate, but they fixed that. Now it's as simple as in FF2.
(\__/) This is Lapinator
(='.'=) copy it in your sig
(")_(") so it can take over the world
As mentioned on the Firehose comments page about this article (http://tech.slashdot.org/comments.pl?sid=634651&cid=24461415):
If the purpose of the Firehose is to vet articles, it's not doing a good job.
Certificates for most domains can be issued by a trusted root if you can get access to one of a few e-mail addresses on the domain. Other certs can be ordered if you commit fraud and uses false letterhead. So the trusted roots are most often not trusted.
If my browser trusts Equifax, then it basicly gives no security at all.
The only way to get SSL working again, and prevent man in the middle, is by zapping all trusted roots in the browser, and let the user individually accept whatever certs he trusts. He will then get a warning every time a server changes vert.
The trusted roots can stay, so the user has an option to see who issued a new cert.
Why would I trust the security of my online banking, creditcards etc to a company in Uruguay ? Everybody does, as it is a trusted narcs^H^H^H^H^Hroot dealer.
CN = SERVICIOS DE CERTIFICACION - A.N.C.
OU = SERVICIOS ELECTRONICOS
O = ADMINISTRACION NACIONAL DE CORREOS
C = UY
There are some majort issues to trusting so many roots, with different validation requirements.
On the other side of the coin, it subsidizes the CA industry just like compulsory auto insurance subsidizes the auto insurance industry.
Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
People who know what they are doing can easily add an exception for a test or in-house cert. People who don't know what they are doing are less likely to be taken in by a phishing site using a self-signed cert. So, what's the problem?
[Insert pithy quote here]
its basically letting go of half of the security for improving the other half.
lets see, what are proponents of this are saying ? they are arguing "ssl is not just about encryption, its also about knowing that you can trust the source"
well, thats basically an entirely stupid approach, when you consider that a LOT of websites who are now using self signed certificates will be just removing ssl encryption rather than pay yearly fees to a 'certified' vendor or annoy their users with the HORRIBLE 'youre being hacked !' style ssl warning in ff3.
what happens ? basically you will have let half of the security go while improving the other half. net gain ? zero.
utterly stupid.
Read radical news here
I think the author makes Mozilla's case for them, by not appearing to understand the risks, especially at a time when DNS cache poisoning has become unusually feasible. E.g., the statement
is simply not true for clients of unpatched DNS servers. It's much easier for an attacker to get a remote user's traffic redirected to a host of his choosing than it is for him to snoop on that user's traffic. Volume-based attacks on DNS become increasingly easier as bandwidth increases, and people who operate botnets have a good chance of poisoning a cache even on patched nameservers, simply through brute force. Meanwhile, that smaller class of attackers who are in a position to actually snoop on traffic are also in a position to use an arp spoofing attack. Encryption is simply not useful without knowing whom you're encrypting to.
If you're feeling lucky, you can always add the exception. You can also sign your certs with a CA cert, and import that into your certificate database. Of course, anyone who trusts that CA cert also trusts you not to generate bogus certs for bankofamerica.com, etc... The solution to the problem is not to make the browser more trusting by default; it's to migrate away from X.509 to a PKI that allows domain owners to generate certs at no additional cost, such as a DNSSEC-based PKI.
I think Mozilla has it 100% right.
So add the issuing server to the list of authoritative CAs. Only do this if you have secure control of the machine but it gets rid of the whole need to add an exception.
Encouraging encryption is good but unfortunately no one can come up with a good way of encouraging encryption whilst avoiding phishing sites (and other attacks). Infact stopping phishing is so bad that it was deemed more important than encryption.
So what's your proposed solution to distinguishing between these two things? Well there isn't one. The closest you get is to say that "Obviously it shouldn't show a green address bar [like a trusted cert]".
The usability problems of expressing a 'dangerous site' are many and until you come up with a way of clearly expressing the distinction between encrypted sites and phishing sites then you won't get far Nat. Firefox 3 made a the right choice for the majority of users who are non-technical.
Perhaps establishing a non-profit issuer is a possible solution?
Similar to the concept of OpenDNS it could be a free (as in freedom) and very cheap alternative to the large commercial certificate issuers?
If I wanted to undertake such a project myself, thereby contributing to the community, what would it involve? (I am ready to pull some cash out of my pockets, but I am no millionaire, just a tech-geek, so be realistic). And do you have the expertise to help establish such an "openCertificate" service?
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
I originally meant to post this as a comment to the blog post, but apparently the author does not care about testing their commenting feature. This alone should already tell you stories about how much thought he puts into this stuff.
-+-
Why in the world are you singling out Mozilla in this ? Every browser has this policy.
Every browser has avenues to add new root certs, too (I can just create my own CA, offer the certificate file on the web, and let users install that; all future communication with a site that has a certificate signed by that CA will not be bothered with these error messages). This may not be 100% convenient, you are correct. But it's not as if it was hard to do if you want to give your users the option of using encrypted sessions.
Oh, and there IS a way to get your shiny new non-profit CA into the main Firefox builds. All you need to do is comply with their procedures and requirements -- which include policies on how you verify the identity of the certificates you sign, how revocations work, etc., and requiring specific minimum requirements in these. If you think you can run a proper CA for free for everybody with proper identity checking and day-to-day operations, do it and get it added !
The default position Mozilla takes is quite simply that the CA should verify the identity of the entity the certificate is being issued to. You may not think that it is important for this to be such a prominent user interface feature, but many people do. Every user can add an exception for your site, you can add a CA of your own, you can get certified by a nonprofit CA (good luck finding one; I agree that most of them are scumbag operations that try to extract as much money from you as possible, but I have yet to see a proposal which both ensures identity checking and revocation management while being completely free ... Maybe you'll find a way).
This has nothing to do with network neutrality. Nothing at all. A more proper comparison would be comparing this situation with that of 2nd-level domain names. You can't get a .com domain for free, either. Nor a .net or .org or most of the country TLDs. You can open up your own Registrar (but will still have to pay dues for domains registered), just as you can open up your own CA. It'll be a rocky road, and it'll not be free -- least of all in work required.
My sites work just fine with SSL certs signed by my very own CA. Firefox displays them just fine (either by adding the root cert of my CA to it, or by simply adding an exception). All other browsers work fine, too. If you have visitors or customers that require validation of your certificate by a third party, you are SOL. But then again, you also would be were the warning worded differently (and there SHOULD be a warning for a certificate that is not signed by a trusted CA or one which you explicitly told the browser to trust. No matter what. Self-signed certs are alright for encryption, sure, but I want my browser to have a default setting of warning me when something is happening that very well could be an attack; especially when I have taken care to add a specific trusted CA (say, the one by my university).
-+-
We use a lot of self signed certificates for a lot of our internal, non customer facing sites, things like Nagios, Munin, etc. etc. most of our IT department are all running the latest Ubuntu Hardy with Firefox 3 and whilst Firefox's initial behaviour when it sees a new site using one of our certs is as described, it's not the end of the world as you just click through it and save the cert.
The real bitch is every few days everyone's Firefox instances are forgetting the cert, so we're having to go through the process every couple of days. I don't know if this is a bug, or new behaviour (aka a feature) but it's really annoying and driving me mad.
The problem with slashdot is that most of its users were bullied and stuffed into lockers as kids!
I've written an article criticizing the behavior in Firefox 3 [...]restricting encrypted HTTP to paying customers
Unfortunately, self-signed SSL certificates are vulnerable to man-in-the-middle attacks - for example, dodgy coffee shop WiFi, airpwn, DNS cache poisoning, corrupt ISP employees, ISP/government conspiracies, and so on.
Now, if it's just you and some friends using your server you can e.g. memorise the key fingerprint. But then, you can also add the self-signed key at whatever computer you happen to be using.
If you're facing a larger audience, however, self-signed certificates do not provide sufficient security as, though they protect against passive snooping, they do not protect against the very real risk of active (man-in-the-middle) snooping.
If you think Mozilla should have redesigned the SSL security model into a web of trust that's all very well, but frankly beyond Firefox's scope IMHO.
Now, who uses self signed certificates or certificates signed by an internal CA?
I do for our extranet which we allow a handful of clients access to. Why should we pay some external company for their certificates when all we need is encryption?
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). Based on the certificate IDs/hash it's possible in this environment for anyone to compare whether the certificate is a trustworthy one, or not. The certificate identification is, in this case, possible.
I don't understand this. You want to be sure that the data transfered is protected, but you're happy to have it redirected to any site.
As to the cost/benefit, how about a cert from startssl? This has the cost of $0 and the benefit of being supported by Firefox. It's not supported by IE unless the user installs a root cert by hand, but then it wasn't IE you were complaining about. Firefox actually seems to be ahead of IE in this regard.
In my opinion the main point the article makes is:
- HTTPS with a self signed certificate is in no way worse than HTTP.
With HTTPS you are protected against all attacks that simply snoops your traffic. You are not protected against a man-in-the-middle attack, but they are much harder to perform. Thus, I believe a HTTPS connection should be showed exactly as a normal HTTP.
Also, think of the new law in Sweden that will allow a government agency to SNOOP all traffic transitioning the Swedish borders. They are not allowed to alter your data, and thus cannot fake a man-in-the-middle-attack.
EVERYthing on the web is susceptible to various attacks. yet, we are not mandating anyone to pay to some 3rd party source for a 'fix' in any of them. yet, it is the case of ff3 and the self signed certs. how come ?
so you people are basically arguing that because there can be man in the middle attacks, we should be forcing EVERYONE into the lap of verisign ?
how populist, how public minded, how democratic.
Read radical news here
When do people finally realize that self signed certificates don't work? If I share your WLAN access in a public cafe it's really no big deal to play man in the middle and exchange the presented certificate for my own. Ok, it's more work than without, but not much (about 5 minutes). The only case where self-signed certificates can be secure is when you manually verify the validity of a certificate beforehand and save it in your cert store. If your first check of a certificate's validity happens to be while I'm attacking you (maybe because you are visiting the site for the first time) you will "verify" my hacked one. And don't tell me about hashes on webpages. Maybe 1 in 1000000 users checks this once in a while for pure curiosity, but not more.
TFA seems to imply that Firefox won't let you connect to a HTTPS server using a self-signed certificate. Not so.
Having just successfully connected to a self-signed HTTPS server using Firefox 3, I really can't see how it differs from (say) Safari or Internet Explorer.
All of these browsers pop up a warning dialogue that might scare off an uninformed user.
All of these browsers also allow you to connect anyway. Look at TFA, you can see the "add an exception" link in the screen shot from Firefox? Click that, and firefox will bug you no more.
So what is the argument? Is the Firefox dialogue box somehow scarier than the equivalent scary warnings in Safari and IE? Is it the little icon of the Customs guy making users worry that if they click on "add an excecption" they'll hear the snap of the rubber glove?
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
Hello,
without some assurance who you talk to (authentication), encryption is useless, since an attacker can insert themselves in the middle (called 'man-in-the-middle-attack -- MITM') as done by some chinese ISPs) without you noticing. Mozilla is 100% correct in their approach, some crypto-faschists would even go farther and not allow an exception through only 4 clicks.
Please learn some crypto before you complain about it.
Best regards,
os10000
It's not like Firefox makes it impossible to access a web site with a self signed certificate. It just makes it very obvious that something is wrong with the certificate, and tells the user that he shouldn't trust it to much.
there close to a billion people on the net that wouldnt tell what to do when faced with such a disastrous looking warning as ff 3 prints out when met with a self signed ca.
also there are equally many people that would rather skip visiting/subscribing to a site when they see the hassle ff3 puts out.
therefore many small service providers, businesses, communities that would not afford a decent certificate will be hurt in all respects, not to mention many users.
excuse me, but this is a very stupid, self righteous and jacobin move.
that is the EXACT kind of thing slashdot criticizes almost EVERY government, country, organization, corporation for, yet, you people are actually applauding it in this case.
Read radical news here
I think the following is misleading:
restricting encrypted HTTP to paying customers
It doesn't restrict ssl's to paying customers, it simply warns if the cert is self-signed, but does give you the option of accepting it anyway. What's wrong with putting good security first, but letting the user over-ride.
The entire article is based on a false premise (and some hysterical shrieking), which is that connection to self-certificated ssl encrypted websites is unavailable. It is simply not true and the author is apparently either woefully incompetent or is dishonest. I smell an ego-fuelled activist. I hadn't been aware of Firefox's behaviour so I tried the self certificated example offered. As mentioned by other posters it's 4 clicks to add an exception. What I really appreciate is that Firefox's dialogues explain the situation in layman's terms, i.e clearly and concisely, and let even an uninformed user make an informed decision. This seems to me to be ideal. It is certainly a much better approach than I've experienced with older versions of Firefox, or with Epiphany or IE6/IE7 where it always feels like a roll of the dice when trying to make a quick decision.
You're right, it's extremely stupid to defer trust to a group of 3rd parties that have demonstrated in the past that they're not really good at verifying the identity they supposedly certify.
Firefox should just have no preconfigured ca and pop up the warning with every new ca it sees, asking "do you trust verisign/thawte/whatever? Here are some links about their track record."
Alas, users are stupid and they'll just click OK anyway.
also do not forget that increasing privacy violation, deep packet inspections, surveillance and snooping is a MAJOR problem in every part of the world as of now.
ssl encryption provides the people with increased privacy, and makes it a tad harder for governments trying to peep on people.
yet, with this self righteous ssl cert move, firefox 3 is actually going to DETER the usage of self signed certs, and make it easier for governments or any interested party to snoop on many web users.
great move. very public minded.
Read radical news here
A warning to the effect that the site's identity could not be verified is what should be done here. And it should take -1- click to proceed (if you so choose, and with an option to permanently add this certificate to a list of accepted certificates.)
One can argue with the SSL approach that handles both encryption and identity with a single solution, but it is legitimate to use self-signed certificates when all you care about is encryption.
The same behavior should apply to email user agents.
Side issue: Whatever happened to the idea of an 'open source' certificate user? It bothers me that there is a list of closed (and not cheap) certificate authorities.
dave
I haven't tried Firefox v3 or even read the criticism, but isn't this an option that can be enabled or disabled under options/exceptions? I doubt that this would get put in there without the option to turn it off. The reason I 'assume' this is because MANY companies accidentally let their security CERTS expire. If someone forgot to renew their CERT, like GMAIL did last month and there was no way to create an exception, imagine the interruption. It took me awhile to figure out what had happened after I upgraded Firefox last time and couldn't get to gmail.
A.) You don't need to buy certs from Mozilla, you can buy them from any number of CA's, for as little as $10. There are some free CA's, as well.
B.) This isn't in any way related to network neutrality.
Interested in open source engine management for your Subaru?
Except that there is nothing compulsory about ff. You are free to trust any certificate you want, the browser merely warns you that it could be a bad idea to do so.
I set up SSL sites as my day job...
I test the setup before the DNS has pushed out using the IP address. Hence I get that message all the time (due to the cert not matching the domain). It's four clicks to getting to the page (and each step gives useful information the first time round) - sure one click would be nicer but it's not something you want to do with a single mistaken click.
I'd rather see this than something that doesn't stand out, or nothing at all when accessing a site that's self signed.
Yes it can be a nuisance if you visit a lot of sites that are self-signed, however, if you're browsing habits are more corporate style, then it's good to know you're going to be warned if something's not quite kosher.
Who is general failure, and why is he reading my hard drive?
Our school uses a self-signed certificate for the courseware. We won't get freaked out because we're CS students (but it's really, really, REALLY annoying, especially if you access public terminals) but I bet the rest of the student population will.
The most ideal interface would probably be the one in IE7 but personally, I'll go for Opera... it's the least intrusive.
As for hobbyist systems, they (the site owners) usually tell their less-than-techy friends to access their sites which is installed with self-signed certificates... (can be due to various reasons from hosting a Trac+SVN server to HTTP authentication over SSL, etc) aside from waving your hand to get them to visit your site, you also have to play tech support for them to get past the esoteric error message.
As for unprofessional webhosters, they usually hand out shared certs to keep the cost down but of course, they also give you an option to get a personal cert... at a price... it's not very convenient for people living at other parts of the world (particularly in developing countries). You don't want (or do you?) to shut them out from online business opportunities just because all they can afford is a shared cert.
Obviously you don't need encryption very badly if you don't care about man-in-the-middle attacks.
They don't call it "auto insurance" for nothing!
Look it's very simple. We'd like to be able to do two things: A) Encrypt data in transit between the web server and the browser. B) Authenticate the owner of the web site. These two things SHOULD NOT be inextricably linked. We should be able to do one without the other. If we had two icons on Firefox, one that indicates encryption in use, another that indicates trust, then that's all we need and everyone is happy. I agree with the author that it's completely ridiculous that we view an encrypted but not authenticated web site as more of a security problem than straight HTTP - that is nonsensical. Let encryption be free for anyone to use on a web site, with or without certificate!
I noted a far more subtle problem with SSL in Firefox about a year ago that deals with Client certificates. They allow users to use a non-repudiation certificate for authentication, which is a subtle but bad thing. It ends up giving the US DoD a free pass while messing with the security of everybody else that uses client certificates.
One good thing has come out of it: when I was interviewing for jobs, I brought this issue up with all of my potential companies. It was a great conversation-piece to hear what different companies would do in the Firefox Position: bow to the wishes of the DoD, screw the DoD in the name of the specifications, or something else entirely...
Reid
The Right Reverend K. Reid Wightman,
Is because people are too stupid to do any research.
If the article author had bothered to do even the slightest bit of it they would have discovered that there are already trusted CA in Firefox.
Startcom (http://cert.startcom.org) is in Firefox 2, Firefox 3 and Mac OS X 10.5/Safari 3. StartSSL (http://www.startssl.com) is in Firefox 3 and working on getting into Safari.
Startcom/StartSSL got into Firefox by following their approval policies. It is perfectly possible for any other provider to do the same, they merely have to bother to comply.
I'm going back to Telnet -- no pesky security certificates to worry about.
I totally agree with the author of the article. He doesn't suggest that there should be no verification of the SSL certificates. He just says that the warning message is an overkill because it scares people from using SSL in encryption-only mode. It's kind of a G.W. Bush approach ("You are either with, or against us.") that I wouldn't expect from Mozilla foundation.
IMHO, the new approach of Mozilla to SSL cert handling is flawed because:
1. The displayed message has the look of an error message, while in fact it is a warning message. You have to read the fine-print in order to understand that.
2. The message gives erroneous suggestion for the source of the (perceived) problem. In 99% of the cases, neither of the following is true:
3. If the Mozilla guys really think that there is something bad going on, why do they have checked by default the "Permanently store this exception" checkbox?
Finally, running running a CA is not an option for many companies. There is a quite heavy administrative overhead (compared to the received benefits) for doing so. Also, what happens with business partners of the company who don't want to trust all of the sites certified by their CA?
I am sorry to say, but this new warning screen is a bad copycat from IE7. I would bet that there is a thread somewhere in /. where the /.-ers moan about the new warning screen of IE7. ;-)
But you only have a handful of clients, who know that you're trustworthy, so it's a non-issue for you.
All browsers post a warning when a self-signed certificate that is not imported into the local certificate store is used. This is NOT a firefox problem.
You WANT to be warned when you have a self-signed certificate thrown at you. Let's say https://example.com/ has a trusted certificate (trusted meaning the signing CA or the self-signed cert is in the local store). If you get a self-signed warning, then you *know* there is a problem.
For lazy souls link to BugZilla bug 433422
Brief of discussion:
SecurityNazis: Self-signed SSL is untrusted!!!!
Admins and Users: Untrusted != invalid!!!
SecurityNazis: But self-signed SSL is really really untrusted!!!!
Admins and Users: Untrusted != invalid!!! We do not care!!!!
SecurityNazis: But we care!!!! Though we do not browse WWW - because it is untrusted.
and so on. Not really informative on its own. Essentially, people who do only one thing with Web - exploit trivial bugs and claim credit for doing so, so called "security researchers" - against simple users who do only surf web - intranet and internet - argue with each other, constantly failing to find common ground. Because they, well, do not have one.
All hope abandon ye who enter here.
If you know of a way to push out certificates to user's home computers that you have no control over I would be very interested to hear it.
Or do most of your users choose to VPN into their work account when they're already at work?
Also, some of us just don't have funds. If I want certs for my organization, they'll have to come out of my own pocket.
what kind of logic is this ?
1. create your own CA and tell your customers to import the CA by clicking here (before putting them in ssl mode). It's really not much trouble to set up your own CA.
first, you are not in communication with potential customers, and they will never communicate with you and become a customer after they see that horrible ff3 warning. you wont even get a chance to tell them what is going on.
second, same goes for many potential website users that are signing up for a community.
additionally godaddy is one of the shittiest service providers on the web. so if the solution you are offering is godaddy, please, keep it to yourself, and even firefox3 too.
Read radical news here
Except that at work, we're part of the International European Grid network. We use self signed certs for everything, and if anything, our self signed certs are more secure than anything any top level CA will ever generate. ie : We enforce air-gap policies around the server that generates/signs the certificates, and a member of the grid was kicked out a couple of years ago for violating those policies.
Think any of your top level CA's do that?
We've had to start using the occasional top level CA on our more public sites due to Firefox doing this, but I'll take our self signed certs over a top level any day.
to ask slashdotters for advice in improving the draft of an explanation of cryptography and certificates that I have begun. You can find it at my website
I submit that this is not off-topic, since one point several people have made is that most people don't understand certificates well enough to be able to deal with the warning that ff3 gives, so if we could get some explanations out there, it might help the situation.
Self-signed certificates are both valid and common with internal Web apps.
We use several where I work, and there is even an internal CA that mints certs for several apps.
And Firefox works fine with these internal apps. I know where I'm going, my antivirus and such are still working, and I trust my internal developers. After all, if they screw my machine up, I'm off the hook. It's an approved app, sir. See, I don't even need an exception.
So there is this one good reason to permit self-signed certificates without undue hassle.
Sheesh. Firefox being stupid? What's next, Google exploiting our data for... wait, nevermind.
deleting the extra space after periods so i can stay relevant, yeah.
http://www.startcom.org/ provides free ssl certificates that are supported by firefox That's a free way to remove the scary dialog...
On the other side of the coin, it subsidizes the CA industry just like compulsory auto insurance subsidizes the auto insurance industry.
Driving is a privilege not a right. Unless you have the money to cover any damages you may cause, it is absolutely necessary to have insurance. The cost of barebones liability coverage is not that high assuming you have a relatively clean record and if not, you probably shouldn't be driving. It seems that today the idea of personal responsibility is falling out of favor.
I'm not not licking toads.
First, I think that the most important line in the article is this one:
But there is absolutely no excuse for it to be significanly less inviting to a normal user than an unencrypted site.
The FF3 behaviour will make most normal users just think, "Oh, the website is broken. I guess I can't go there." They won't even read the error message: they'll just see that there is one, and give up.
Or, depending on IE's behaviour (which I do not know in this particular case), they'll see, "Oh, I can't get to this website in Firefox. But hey, it works fine in Internet Explorer! I guess Firefox is broken, and I won't use it anymore."
Second, and probably more importantly, either you missed a very, very important demographic among those who use self-signed certificates, or otherwise don't want to pay the extortionate fees charged by the corporate CAs, or you severely misunderstand and underestimate the importance of "unprofessional" and "hobbyist" webmasters.
Just because I want to have the possibility of encrypted traffic for visitors to my website doesn't mean that I'm bringing in loads of money by said website, or that I want to spend some not insignificant sum on a recurring basis for what is, for me, just a fun hobby, for which I'm already shelling out a not insignificant sum for hosting.
I'm seriously hoping that your definition of "unprofessional webhosters" means "people running for-profit websites (that actually make a profit) who are just too cheap to actually buy a certificate," and not simply "amateurs," because it is on the backs of those amateurs that the web was built.
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
Thats what they said about IE6 - you don't HAVE to write your web pages twice (once for standards and once for microsoft) but if you don't, you're cutting out a huge portion of your audience ;)
Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
You want him to purchase a certificate for his own firewall for internal users?!?! So you're saying his users shouldn't trust their internal firewall until a commercial license is made with the outside world.
This is where I have to agree with other people on here that for some people, SSL is only about encryption and this "trust" scenario you believe in is horse poo poo. Nor is it valid in this scenario therefore the problem is the browser, not the cert.
I would agree that the solution is not just allowing self signed certs to be viewed without warning. However, there needs to be a way for new / not-for-profit CAs to be added to Firefox, and right now there isn't. Yes I know they have an official policy for adding CAs. There is only 1 CA that tried to be included that I know of, CACert, they app'ed in 2003, and as of July 2008 a decision still isn't made. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=215243
Yet if you look at your own CA list in the Options menu, you can see things like the Taiwan Government CA, the GTE Corp CA, Swisscom Telecommunications CA, the GoDaddy Group, and others which I'm sure all of us would trust a whole lot less than something like what CAcert is trying to build.
Just my $0.2
You buy a purple T-Shirt and 6 months later purple is out of fashion. Clearly the manufacturer's fault, right?
Yes, SSL Certificates from a CA *are* expensive. Yes, you can encrypt with a self-signed cert. But that encryption is worth nothing at all. Because anyone (latest DNS vulnerabilities for instance) can easily forge these certificates, you don't know who you are communicating with in the first place. Of what use is point-to-point encryption if the man in the middle is undetectable?
Yes, it 4 clicks to define an exception rule are a pain in the ass. But because it's that painful it will cause people (like the author) to think twice before they use a self-signed cert next time. So making the web safer in the end. Don't make it too painful (will hurt adoption of product), but painful enough so that decision makers get worried. I think FF3 behaves perfectly in that respect.
Are there any other similar?
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
"Instead, it shows a [...] warning that requires 4 clicks and an 'add an exception' dialog box to bypass. This behavior means that a public web site basically can't be encrypted unless they are willing to pay an approved vendor a yearly fee for a certificate."
I don't see how the second sentence follows from the first one. If you want security you need to make sure people don't click blindly accept-accept-accept!
It's hardly a "mere" warning; it's a gigantic stop sign.
If a little yellow bar like the "remember password" bar came down and said "this site is encrypted, but its identity cannot be authenticated. Be aware that, like any normal (http) website, this one may not be from who it says it's from" then it would be completely different. Instead they interrupt the browsing experience with a very unfriendly message that non-tech people will not have a chance of understanding.
This is bad because, as the article says, some sites will end up having to buy certificates when in fact they don't need one, and others will end up not using encryption when in fact they should be.
Bear in mind the three levels of security:
1) no-ssl: offers neither encryption nor authenication
2) SSL(self-signed): offers encryption
3) SSL(3rd party signed): offers both
why is that that no.2, which is a significant improvement on no.1, generates such a severe warning message?
When you go to the store to buy beer. You must present an expensive piece of ID to show you are of age, just saying you are an adult will not get you beer. This is not really any different, except the state government not the CA's grants the certificate. Now if you are calling for the CA's to be replaced be a government agency because it might be cheaper, then maybe you are right. But self signed certificates are inherently insecure and should never be accepted. Just like no sane store clerk would sell a 10 year old beer because he shlocked together a homemade ID saying he was 21, so sane user would accept a self signed certificate. END of discussion.
Our school uses a self-signed certificate for the courseware.
Than tell the admins to fix it. School environments are hard to do, because you have a lot of non-standard clients. So a public cert would probably be better for a school than an internal CA (which would make sense for a company).
Again: Firefox and IE both give a very stern warning that what you're going to do is potentially risky. This is the *RIGHT* thing to do - if that wasn't the case, with the recent DNS issues it would be easily possible to spoof https://www.yourbank.com./
Basically, don't blame Firefox if your cost-cutting measures break on you - it's your own fault.
you NEED encryption to provide better security (through encryption), and most importantly, PRIVACY, to your community users, clients, vpn users, whatnot.
especially in an age that almost every government has started snooping and eavesdropping internet connections.
Read radical news here
If you are to lazy to use the system like it is supposed to be used then you only weaken it. Self signed certs should really only be used for testing. If you don't want to pay one trillion dollars for a certificate, create your own authority and get your users to trust you: Tools > Options... > Advanced > View Certificates > Authorities > Import...
So what we want a certificate in the first place? Yes you the nerd on the third row! because we want security and how security can be implemented when you need to accept a self signed certificate from bad boys inc boys just chip some money (I know less beers) and buy a certificate And do not blame mozilla because they ARE RIGHT and you are SOOOOOOO WRONG
ff2 warning was just a commonplace warning. not 'YOURE GETTING HACKED !!' style overly alarming one like the ff3.
Read radical news here
exactly.
It is totally ridiculous that FF makes it easier for users to type in their credit card number on http than self-signed https.
I've seen quite a lot of academic institutions use self-signed certificates.
And I have to admit, the first time I saw the self-signed certificate error, I didn't actually read it and assumed it was a dead server / bad link and went to a different site...
If you run a self-signed certificate you still can get the man in the middle protection.
There is no difference there, the only difference is that you don't have to pay for a certificate from a well-known root CA. The "insecurity" of not using a well-known CA is only a commercial stunt.
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.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
SSL certificates provide honesty-box security
- People will come to your site
- People will come to your site
- People will come to your site
- People will come to your site
- People will come to your site
The whole PDF is a highly recommended read full of sad truths.
Unfortunately, it is VERY hard to recondition users. I don't blame Mozilla for
trying (in fact I completely agree with the change), but it will probably fail.
If you really need to use self-signed certs is there anything stopping you from including your own CA cert in a company customized version of Firefox that gets rolled out?
I'm kind of annoyed because I work for a web host and now people who use any sort of domain mirroring are going to be completely fucked rather than having a semi-dodgy box come up when their CN doesn't match the web address.
The author assumes that this is a problem that needs addressing by doing what?? Making it easier to accept self-signed certs?
As usual, the he can't see a tree because of the forest. SSL is used for two purposes, encryption and authentication. Self-signed certs, as noted above, fail the authentication test.
So the real problem then is that sites that just want to use encryption have to purchase a cert, or get what is claimed to be an obscure warning.
The issue isn't about SSL, it's about the encryption.
My first thought is that it's so much BS. The odds of someone actually listening in on your HTTP transmission is extremely small, unless you are using a wireless transmission that is not secured. To tap an IP stream would require physical access, and unless someone is an employee at a provider is highly unlikely.
But .. there still is a very slight risk.
So .. why doesn't some numb-chuck come up with a new HTTPX method that just does encryption??? Duh!!!! SSL model without the certificate. Coordinate it so that Apache and Firefox have it available at the same time. Sure, IE won't have it but it has to start somewhere.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
mod up. Thats the fallacy in TFA.
bickerdyke
Is this whole thing about admins thinking that self signing a certificate is actually worth something? If you can't afford this CA stuff just don't have encrypted giberish, ok?
I mean, really. What's the point of a self-signed certificate? Name a real life scenario in which signing your own certificates makes any sense? Why should a web browser trust those sites more than a normal person would trust a guy who has signed his certificates? Because this blog writer and own blog linker has managd to somehow connect it to net neutrality?
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
nothing in the world on, or off the net is guaranteed.
its all about making it HARDER to be put in the place of a victim.
and its not only about government either. one rather eavesdrop a website's connection and get the personal details of thousands of users, than try to hijack 1-2 self signed ssl connections. personal data would fetch much more higher price on the black market.
no. im not delusional. you are careless and uninformed.
Read radical news here
here it is: you need to register though...
Who runs a business will buy a 10$ cert.
Directly contacting all your users or customers by phone or mail will cost more than 10$.
Not doing one of the above leaves users in danger and not having a clear and understandable-to-the-final-user statement from the browser gives a false sense of security.
it's not "die net neutrality, die" but "go final user security!"
Here's the problem with this gentleman's analysis:
1. Without a third-party signed certificate, you're vulnerable to a man-in-the-middle attack.
2. If you accept the connection without a warning (it's no worse than plain http, right?) the user won't notice when a normally signed site (like his bank) suddenly presents an unsigned certificate.
Then again, the user probably won't notice if a normally-encrypted site like his bank suddenly starts using plain http instead of https.
There is probably a middle ground, like creating another URL type (in addition to http and https) which encrypts but doesn't check certificates.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
and here is the link... https://addons.mozilla.org/en-US/firefox/addon/6843
I think it is quite reasonable for Firefox to say something like "the certificate is valid for the domain, but it is not warranted genuine by a third party. If you believe you are accessing a site which is not connected with banking, finance, gambling or on-line purchasing, this is unlikely to be a security risk".
Alternatively, FF3 needs a simple way to import a certificate from a trusted supplier, so I can supply one as part of the new account welcome package.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
If I share your WLAN access in a public cafe it's really no big deal to play man in the middle and exchange the presented certificate for my own.
You can't just snoop the packets, it has to be an active MITM attack with specialized software to do that. Adds a layer of difficulty. Not insignificant.
The only case where self-signed certificates can be secure is when you manually verify the validity of a certificate beforehand and save it in your cert store.
Quite a common scenario. If I frequently visit a website's HTTPS site on my laptop - e-mail provider, small online store, etc. - from home, I'll already have stored its cert. Your attack will therefore be noticed when I access it from the WLAN. It's not as good as proper SSL, but as others have said, it's a mile better than accessing stuff via http://./
== Jez ==
Do you miss Firefox? Try Pale Moon.
Not really a problem, just that the self signed certificate is unknown to your browser.
Don't forget that once it is installed it is no different from a well-known certificate and SSH uses the same approach by allowing you as a first-time user to accept the server signature and barf if it has changed.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
now, there are a lot of websites, services, whatever you name it, that would not care to (or even afford to) acquire single or (in many worse cases) wildcard ssl certs for their services on the web. they will just probably let go of self signed certs, and dont replace with anything.
it will cause easier snooping of personal details of countless millions for people, because it will be easier without any encryption to make snooping harder.
result ? personal data of countless millions going out to black market.
if you are not still aware EVEN if you get your connection hijacked by a man in the middle attack somewhere, you can freeze a bank account, you can chargeback a credit card charge, you can cancel a credit card and do many other stuff.
but, if your PERSONAL details go out in the open, your name, address, social security number, main email, parents' names, (insert whatever sensitive info as you like), you CANT cancel them or take them back or do ANYTHING to prevent them getting spread in the wild, and used for ANY purpose. there is NO way that you can do that.
excuse me, privacy is more important. this 'security' minded move by some programmers will jeopardize millions of people in an angle they never apparently have thought about.
Read radical news here
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.
This is merely a symptom of the confusion that is inherent in SSL. SSL mixes cryptographic transmission security (nobody can sniff what's on the wire, nobody can alter the data) with endpoint authentication (the server is what it says it is). The result is that web browsers like FF abandon the exchange upon encountering a self-signed certificate, since those can be spoofed and would thus break endpoint authentication, even if you just want cryptographic transmission security.
Ideally, these features should be separated, or even better, data transmission be encrypted by default no matter whether the server is end-point authenticated or not. One could then put authentication on top, be it certificate authority based, trust network or web-of-trust based, or bootstrapped by encrypted key exchange where the key is a password or a two-factor authentication mechanism.
This is a well known attack vendor: Make a web page that looks like a real bank site and trick people into visiting it. This prevents those sites from using HTTPS, as it makes entering them pretty hard and obvious. Mission solved. The collateral damage is admins who don't want to spend the time to properly set up their CAs. Nothing to see here, move along. As to subsidizing the industry, if you feel you can do a better job being a default CA, please contact the Mozilla foundation and prove it.
You mean Verisign right? Since they own over 70% of the market. Oh and crazy frog. Seems like they have a monopoly on being annoying.
In a world where phishing is a considerably bigger problem then someone snooping your connection, I have to agree with how Firefox functions here. Self-signed certificates provide no way to authenticate the website which is even more important these days after the recent DNS exploits.
I think Mozilla's large "Failed!" message is much better than a default-accept of self-signed certs with a small warning message that would be ignored by 90% of users. Besides, Firefox will still allow self-signed certs after manual intervention.
ÕÕ
since it will make it harder for any third party to snoop on your connection and information is being sent. you can get your connection hijacked by only one party at a given time, but more than one party may be snooping on your connection at exactly that moment.
Read radical news here
I really don't support anyone that says paying through the roof for a trusted certificate is better than a self-signed certificate. With exception of business validation (which often comes as a joke) trusted certs are really no better than saying this person paid money for a brand name. It's like A&F jeans versus Walmart jeans.
The problem with FF3 is that it denies you access to websites with self-signed certificates until you explicitly install the certificate (as an "exception"). Odds are you're only visiting such a site once in your life, so installing the cert is by far a larger security risk than allowing the user to temporarily accept. This is up there with Vista's annoying security policy.
I can see more businesses paying for certificates from Verisign and the like, but it's a punch in the face of net neutrality when you see how this is hurting small business owners. They end up charging more to their customers and the customers leave for a cheaper big-box solution which kills little guy and eventually the local economy.
This also makes rush/trial/beta setups very annoying where the client has not shelled out their cash for a trusted cert. They want their website out there immediately but they've only paid for part of the package. If you give them a temporary self-signed cert, it gets put on the FF3 exceptions list and then it sits wasted on the machine once the trusted cert comes around. And you also have to waste time explaining to them how to install the cert.
You probably won't, but I'd support a net-wide protest against trusted certs and see what Mozilla does about their stupid policy after everyone spends half an hour of their day configuring exceptions in their browser. At least IE lets you temporarily accept, but I hate IE.
Joe Average User does not understand SSL, self-signed certificates, or anything else about encryption and security. Even though snooping on a wireless connection is easier, in today's world, the attack Joe will MOST LIKELY face is a phishing email sent by an adversary who ultimately wants to execute a man-in-the-middle attack. Granting self-signed certificates the same status as "verified" (And I agree, the system isn't perfect by any means) would make this kind of attack even easier than it is today.
I can educate my mom to make sure "the little padlock" MUST be locked before she does anything on her bank's website. I can NOT educate her to check the certificate's contents.
For people who want encryption without authentication, the solution is not to grant self-signed certs the same status as verified certs. What we need is either a new protocol for encryption-only connections, or a user-friendly way in browsers to do this using existing protocols, for example HTTP-over-SSH.
He who laughs last, thinks slowest.
In the vocabulary of international politics, we need to "trust but verify." Which means no trust at all.
There needs to be a mechanism where a vendor or site can send you a certificate in a way that can't be spoofed. And can then be verified. Maybe it is an email, maybe it is snail mail?
What I don't like about SSL in web browsers, is that they have ignored the "verify" aspect of trust by abdicating the responsibility to a "pay for trust" regime which is bogus. If they can pay, they are trust worthy, right?
Ideally, I should be able to receive a password in the mail (or some form of communication) to unlock a "key" file sent to me from someone I want to trust. I then unlock and install that key on my system and only keys *I* trust get trusted.
It should be easy and standardized across most platforms. Anything less is broken.
Problem is that your "2" doesn't exist... the way SSL (and most other secure protocols, as SSH) is designed, having encryption without authentication is pointless, because man in the middle attacks are too easy to set up.
With SSL, the real 3 options you have are:
1- no ssl
2- "1 way authentication" SSL (usually only the server has a certificate: this ensures the client it is reaching the right server, but the server cannot trust the client)
3- mutual authentification SSL (aka "strong authentication": server and client have a certificate)
I think TFA is completely out of topic and blatantly ignorant: what would you think if SSH wouldn't warn you when the host you're trying to connect to has changed ?
The problem about SSL isn't to warn or not about self signed certificate (you HAVE to be warned about self-signed, and strongly, else anybody can easily get "average user's" bank account info, for instance). What is at stake is the lack of competition among public SSL Certification Authorities.
In general, don't try to solve a political/competition problem through technical/IT means, this won't work. Solve such problems through political/competition means (such as laws, regulators or open standards).
If you accept a self-signing certificate without verification, you get private communication with an unknown third party. The author of the article seems to assume that such communication is useful. However if you don't want other people on your network to see the data you are sending, then why would you send the data to some unknown entity? Certainly it's no worse than a plain http connection, but it is also no better, and may provide a false sense of security. If you aren't going to provide any real security, be honest about it, save some resources, and use plain http.
Self-signing certificates are useful if you pre-install the certificate on the clients, but in that case you will not see the warning.
I have actually used self-signing certificates without pre-installing for my own personal servers, but the message is not a problem in this case. I considered the risk and consequences of a compromise low enough that it wasn't worth the effort to pre-install, especially since I can save the certificate and will be notified if it changes. However this scenario of laziness does not further the argument for creating a less severe warning. I can't think of a use-case where general users who would be intimidated by the warning should be accepting a self-signing certificate.
Driving is a privilege not a right.
This is unconstitutional statist propaganda. According to the Declaration of Independence and the Constitution, the people create a government and give it limited powers necessary to maintain order and do other important common tasks. Regulating driving is surely one of those tasks. I have no objection to requiring insurance. But the government does not confer privileges on its citizens. It's the other way around.
Is the proxy transparent or not?
If transparent:
Does the proxy generate a certificate on the fly with a matching hostname? If yes, just import the proxy root certificate.
If not:
Then you shouldn't have the problem you're experiencing. Could be something completely broken with the proxy.
> If you run a self-signed certificate you still
> can get the man in the middle protection.
> There is no difference there, the only difference
> is that you don't have to pay for a certificate
> from a well-known root CA.
I assume the CA must somehow verify (no matter how minimally) that the one applying for the certificate has the name written on the certificate. This is the only difference. If you visit a site and it has self-signed certificate, you know you are talking to somebody, and that somebody can keep the message secret if he choose to. But you don't know who that somebody is. If you are talking to somebody who poisoned the DNS cache, masquerade the site you want to talk to, using a different self-signed certificate, you are absolutely ignorant about it: your experience will be exactly the same.
That is, unless you have some alternate way to verify that the certificate you see is coming from the one you want to speak to. If you can contact that guy by phone and take the time to have that guy read out loud the MD5 of the certificate and you carefully check every digit in it, no problem. But most people would rather have a CA do the job. Even if the CA are somewhat lousy.
It's "attack vector", not vendor.
Bear in mind the three levels of security: 1) no-ssl: offers neither encryption nor authenication 2) SSL(self-signed): offers encryption 3) SSL(3rd party signed): offers both
why is that that no.2, which is a significant improvement on no.1, generates such a severe warning message?
Well...no. 2 also offers authentication if you consider that you signed it yourself (and it's assumed that you trust yourself because, after all, if you don't trust yourself you can you trust)? However, it seems to make sense that since there are no 3rd parties involved why does there need to be a warning? Perhaps people should just install the public certificate of their site into their browser.
While I agree about the need for insurance, handing a market like this to private companies is a bad thing...
You leave companies with the ability to create huge profits from a captive market.
What we really need is non profit insurance, so those of us who don't make claims are not having to subsidise those who do. Despite being a young male with a powerful car, I have not made a single insurance claim (or caused anyone else to do so) despite driving heavily over the last 8 years. And yet i still have to pay ridiculous amounts for the insurance, to generate profits for the insurance companies and subsidise people who drive far more recklessly than me.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
number 2 is _not_ a significant improvement over number 1, simply because from a security standpoint, you have gained almost no security by encrypting if you don't know whether you're communicating between the person you want to or perhaps some fake site that looks similar, or a man-in-the-middle attack.
the only improvement is in the case of a purely-passive eavesdropper -- not much of an improvement at all. For eavesdropping purposes, if you can passively eavesdrop, you can probably actively eavesdrop and interrupt or manipulate the connections, because you've got physical access to some wires or routers or just have a laptop running airsnort software in a cafe.
furthermore, having people get used to using self-signed certificates is bad, because it lends man-in-the-middle attacks more apparent legitimacy. so of course eve couldn't fake the signature of the real key, but if any signature will do...
i don't like the existing certificate authorities ($50-$100 per year for a row in a table? sheesh!) much either, but they're needed to have trust between people who have not met before.
the privacy of one's mind is important.
you do have something to hide.
* Unprofessional webhosters (good riddance)
The "unprofessional web hoster", that we use at work here in Greece, offers a full spectrum of services (just about anything you can think of, including personal service--you have a problem, you call them and they fix it while you talk, not some person at a help desk who may or may not forward your request) at a rock bottom price. Their competitors have much higher prices and will charge you for anything beyond the basic web hosting package. You want more than the default few MBytes? That's extra. You want a database or php? That's extra, too. You want to park a domain? You need to buy the domain parking package. You want it now? Sorry, it's going to take 24 hours!
If the cost for all this is that we have to connect to the web site's control panel (which the other providers don't, well, provide), using a self-signed certificate, it's good riddance to those other providers!
Thats what they said about IE6
I think comparisons to IE6 count as Godwinning the thread.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
Sigh. You don't disclose your private key to a third party when you request a certificate. You provide the public key, and the third party signs that with the private key corresponding to a CA certificate. Neither party reveals a private key to the other, or to anyone else.
2) SSL(self-signed): offers encryption
But unless there is some warning about invalid certificate it is subject to man in the middle attacks. Also, unless you check the certificates every time, allowing self signed certificates would allow man in the middle attacks even against sights that have secure signed certificates.
Driving is a privilege not a right. Unless you have the money to cover any damages you may cause, it is absolutely necessary to have insurance. The cost of barebones liability coverage is not that high assuming you have a relatively clean record and if not, you probably shouldn't be driving. It seems that today the idea of personal responsibility is falling out of favor.
Actually you're both correct and incorrect. Most people are not driving, they're traveling. And that activity is codified in common law as a right, movement by people by any means. Those who make money from either hauling freight or passengers are driving, and that is the legal definition of transportation as noted in "Black's Law Dictionary".
If you desire further examples, check out your state's (I assume you are in the US since your first statement is a commonly stated incorrect mantra) transportation statues/codes/laws and use a legal dictionary for any term not explicitly defined in such.
I responding to your post because that outright lie needs to be squelched.
"It seems that today the idea of personal responsibility is falling out of favor."
Exactly but it's the other way around. If they would really let us be responsible for our own actions they would let us choose wether we want to pay for insurance or not. Being obligated to buy it means they don't trust you in the first place.
Just like the regulations for 'safe-driving': They should just let people do whatever they wish. If you can talk on your cellphone while driving OK, if you create an accident you should suffer the consequences and that's all (the problem is with the people that escape punishment because of the fucked up judicial system).
ics
There are indeed various instances where ID verification isn't needed. I can't think of any though where encryption IS needed and ID verification isn't. How do you know you're sending your sensitive data to the right server?
"If a little yellow bar like the "remember password" bar came down and said "this site is encrypted, but its identity cannot be authenticated. Be aware that, like any normal (http) website, this one may not be from who it says it's from" then it would be completely different. Instead they interrupt the browsing experience with a very unfriendly message that non-tech people will not have a chance of understanding."
I agree. I think it is appropriate to warn the user, and it should be made clear this is unnacceptable on a site where banking or credit card info is involved. But completely alarming the user is overboard.
I use self-signed certs every now and again where I am trying to protect passwords, but there is not a big security risk.
That said, a godaddy cert is pretty darn cheap these days, so I do it fairly rarely now.
The only athletic sport I ever mastered was backgammon - Douglas William Jerrold
I use a shitty $10 certificate brand for my servers, however the dedicated server customers have no CA signed certificate, because everyone is tight. They're tight for a reason, as it's tough to compete in the Australian market. The company I work for has a lot of dedicated servers, and I'm not going back to update them all to a self signed certificate with the common name of *. It's too much hassle. I'd rather just use FF2 or Safari until someone creates a version of FF3 without this bullshit in it. It's just not worth my time. They should have an option to disable this with about 5 warning signs: Warning this is dangerous! Only enable if you know what you're doing! GIANT BAT BALLS WILL FLY OUT OF THE SKY AND INTO YOUR MOUTH!
This is also wasting IP addresses.
Problems with FF 3 and online banking and my websites plesk control panel made me switch back to safari as default browser.
"But the government does not confer privileges on its citizens. It's the other way around."
They teach you this but it doesn't work that way. People of the USA have an illusion of freedom
For this problem to be solved, the most popular F/OSS browser(s) must accept self-signed certificates. If Mozilla is unwilling to change their policies, it would be worth the effort of trying to create a *more popular* fork with full SSL functionality.
That's great, and scratches YOUR particular itch.
What about phishing?
Or did you somehow conveniently forget why this feature was enabled in the first place?
Your solution (to seamlessly, silently accept self-signed certs) opens to door wide open for attacks that impersonate well-known websites.
While providing a security warning isn't the only way to solve the problem, it is in fact a step in the right direction.
Let's weigh the stakeholders, shall we?
A) Site operators that want to save some green not buying certs and rolling them at home.
B) Clueless end users that have effectively been trained 'if you aren't warned about anything, the coast is clear'.
Mozilla chose B), and frankly I think this does the most to serve the common good.
In short, your article could well have another title - "Mozilla SSL policy bad for the Phishing" - and that would be a Good Thing(tm)
SSL detecting a man-in-the-middle is a feature, not a bug.
Hmm now Microsoft, they're a well-known attack vendor. :-)
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
No, it's not as simple. I could do a one time exception very easily in FF2. Now it's easier to give a permanent exception.
And certificate authorities email your certificate "in the clear" because that is exactly what you do when you put it on your site. It is called a "public" key for a reason. It can't be used without the private key so it doesn't matter if everyone in the world has it.
How about
* All sites for whom authenticity is a non-issue and data security is the only concern?
This policy adds an unnecessary and arbitrary cost to sites for whom the risk profile does not match the protections offered by authoritative CAs, forcing them to buy a product that they do not need.
Oh, and don't bother retorting that "they're not forced", let me preemptively shoot down that silliness right now.
I hate printers.
Problem is that "2" doesn't happen.
Think of this example: I "encrypt" some confidential data. However, I've encrypted it so that I don't know who will be able to decrypt it. Does that make any sense?
Why was I encrypting it? So a criminal couldn't steal my credit card number? What if I had just encrypted it directly to that criminal? Oops! This encryption didn't help me at all.
If I want to send someone secured data I first have to define clearly and be sure of who I am sending that confidential data to.
With a little thinking you'll find that not authenticating the end users of an encrypted channel is just moving some bits around and is only as secure as your network. Meaning you might as well be sending clear text and save some processor cycles.
Now you can accept self-signed certificates, but you had better have a different way of authenticating the cert than the rest of us use. An example of this would be something from an internal corporate network.
//TODO: signature
If a little yellow bar like the "remember password" bar came down and said "this site is encrypted, but its identity cannot be authenticated. Be aware that, like any normal (http) website, this one may not be from who it says it's from" then it would be completely different.
Yes, it would be completely different. Joe User would ignore it.
Bear in mind the three levels of security: 1) no-ssl: offers neither encryption nor authenication 2) SSL(self-signed): offers encryption
I don't think you understand how SSL works. Guaranteeing data confidentiality without a valid certificate is impossible.
3) SSL(3rd party signed): offers both
why is that that no.2, which is a significant improvement on no.1, generates such a severe warning message?
There is no such thing as no.2. In fact, it's worse than no encryption at all, because even someone as (seemingly) technically minded as yourself is fooled into thinking that it exists. Without certificate validation you can be subject to a man-in-the-middle attack without being aware of it. You might as well be using ROT13. Sure, it's "encryption," but what's the point?
"Well kids, you tried your best, and you failed. The lesson is, never try."
you are missing two critical points:
1.- saying that it is a privilege is not the same as saying that the state concedes privileges, as this is actually tautological. Given the state is an organization built by society to ensure some form of regulation that makes it possible to enjoy certain privileges to all, the existence of the state is a material necessity to the existence of those privileges, and saying that the state is the origin of those privileges is the same as saying that some tool is the origin of the product, when it's the other way around: the tool exists only in the extent in which it is useful to getting the product done. The same thing happens with the state: it exists solely to make the availability of privileges to all.
2.- you have to take into account the rather obvious material considerations that render all this libertarian rants senseless. To enjoy driving, you need a lot of social resources that enable you to do all things related to driving, from getting a car, to using roads, etc. to provide for this resources, we the people have decided to give some other authority to accomplish that which we need to "drive" and that we can not accomplish by ourselves, e g the state. Does this materiallity that makes the state necessary for the enjoying of some (you would say natural, i'm sure) privileges make the state the _origin_ of this privileges?
you have three choices here: 1.- no 2.- yes and the correct one: who fucking cares? this disctintion between the genealogical role of the state and the material role of the state is just a pile of idealistic, liberal (in the proper sense, go look it up), primitive and naive crap.
both points are very similar, but they are two distinct points, nevertheless.
(and don't even get me started on the idiocy of 'granting' privileges to the state. that's like saying that corporate personas have rights!)
---
"america: the only place in the world where 'liberal' means statist, and 'libertarian' means letting the poor die in the streets".
entia non sunt multiplicanda praeter necessitatem
looks like I will have to switch to internet explorer to access self signed https extranet. There are various cases where you do not need any third party to prove your identity. Firefox 2.X was already quite annoying with this. Firefox 3 seems to be even more.
I'm sorry. You installed Firefox 2.x and Firefox 3. You read Slashdot. You are familiar enough with some web security and encryption lingo. But... you don't know how to add a site into the "Allowed" list?
A self-signed certificate is smoke and mirrors. In any situation where I can listen in, I can arp spoof at least (or maybe I've hacked a router?) to hijack the session. Self-signed certs can be easily spoofed, because they contain the same data and raise the same warning; CA signed certs contain a CA signature and don't raise a warning, or raise warning that the cert has expired.
Replacing an SSL certificate for an active MITM attack is trivial in any case where you could otherwise eaves drop on a plaintext conversation. Self-signed certs make this attack totally invisible in most cases (100% of first time visits, and any further visit where you don't check to see if the cert has changed).
If you want SSL to work without any warnings or prompts, set up your own CA and distribute the root cert. Then you don't get used to clicking through a warning, AND you avoid a potential MITM attack.
You can give your cert to as many people as you like.
You should NOT give your private key.
Public and private key works together and there's no way to find a private ley from a public key and the reverse (If you find a method, you'll break all the crypto !)
Some CA can generate the private ley for you but it's not a good idea.
Best way is :
- generate a private/public key on your server
- generate a certificate demand (signed with your private key)
- send the certificate to the ca (you can use a safe way as you already know the ca cert)
- the ca check this is you
- the ca sign your certificate demand with it's private key (and I think your public key)
- the ca send you the certificate
- you install the certificate (only you can decrypt with your private key)
Firefox should absolutely put up big warning lights and make it difficult to use self signed certificates. Firefox is absolutely doing the right thing. There are lots of reasons for this but the first obvious one is that a self signed certificate is completely vulnerable to a man in the middle attack.
What you really want is something else which I suspect is one of these:
- A different way make an encrypted connection between a browser and a website. This should be completely different from the current SSL/TLS/HTTPS.
- A Certification Authority that is free but does a strong validation (vetting) of who the person, or organization, requesting the certificate is.
Is non-repudiation. I think the 4 clicks is excessive, but one of the whole points behind SSL is to prove that the site you're talking to is the one you want to be talking to. Especially today with phishing, dns cache poisoning, etc it's pretty important to be communicating with a site that has a valid certificate.
Self-signed certs are fine for development or personal use. If you're using it for that purpose, you have to only accept the certificate once and you're done.
Anyways, SSL certs aren't expensive now, so if you have a need for one on your site, just go to godaddy and cough up the 30 bucks and quit complaining.
I can confirm that myself too. I ran into that yesterday when trying to visit a site that came up as a search result. It definitely had the option for me to click to get me to the site. It just warned me about the site's certificate, that's all.
I dream of a better world... one in which chickens can cross roads without their motives being questioned.
but i'm affraid that you are making two different points as it were one:
1.- profit
2.- distributive risk assesment (to call it somehow, IANAIA*)
and your gripe is with neither: your problem is that the insurance company does not have a good enough method to distribute the amount of risk to you, and in your particular case, you are personally less riskier than your category. since you are below average than your group, you're SOL. but this is not a gripe with profit or risk subsidies, it's a gripe with the bluntness of the statistical system used to build tiers of risk.
neither profit nor distributive risk assessment have anything to do (necessarily) with crappy calculations.
but i agree that we should have non-profit insurance, but for other reasons.
* insurance agent?
entia non sunt multiplicanda praeter necessitatem
I am not a DNS expert so feel free to correct me if I am jumping to any wrong conclusions here..
It seems to me that the problem (as TFA discusses it) revolves around the use of third parties to tell your browser whether to accept the certificate in terms of authenticity.
If the concern of browsers is to ensure the server providing the certificate is the real one, why are they/we not using something like the SSHFP or CERT DNS record types. If my reading of those two is correct the system could work thus:
- user requests www.foo.com
- browser is presented with a certificate by the www.foo.com server
- certificate cannot be validated by signing authorities so
- browser validates this against the DNS/CERT and/or DNS SSHFP entries
If by this point the browser still cannot verify the authenticity of the server providing the certificate it can throw up a warning to the user. Okay so a MITM attack could provide false DNS records for particular/any domains but they could the same now and redirect a cert lookup to their own spoofed "certification authorities".
Not that high? Either you have waaaay too much money, represent an auto insurance company or you live in another world. If you're young and don't have kids, the cost of insurance is going to be well over $100 a month, no matter how clean your record is. My husband and I are both over 35 -- he's 46 actually -- but since we don't have kids, the lady across the street with a DUI on her record pays no more than we do. And the excuses they come up with to charge you more! You will pay more if your car is red or purple, did you know that? Crap like that is just a scam, legal or not.
I dream of a better world... one in which chickens can cross roads without their motives being questioned.
I tihnrd this complaint.
CAs are total ripoffs. Either we only allow trustworth CAs in the list, or we allow them all. Here are the results:
a) A small, highly cliqueish cabal of "trusted" operators who, by necessity, must prevent new entrants into the market for CA services, lest the web of trust be broken. RESULT: Webmasters are all screwed by the ridiculous prices for certs that will inevitably result from the monopoly or cartel, ultimately meaning fewer web sites can afford security at all and either stop operating or just don't use security.
b) A highly diffuse CA industry that has no trust anyway, thus serving no purpose but to annoy web masters and users who must register with some two bit shitty company for a perfunctory cert that they could sign themselves.
Both options suck if you ask me.
Down with CAs. They are not necessary. Customers should just learn not to buy from www.amaz0n.com
Why is there a need for a whole business around this? Where's the whole industry preventing me from walking into a dark warehouse in a nasty part of town with a large sheet of carboard and a target logo drawn on it in crayon? It's called common sense. If you're going somewhere to spend money, exercise caution.
Caveat emptor. Just because it's in Latin doesn't mean it's irrelevant in the modern world.
I hate printers.
I run sites with no commercial CA. I run my own CA. It is very easy to do with openssl. The key is that the sites are used by limited clients. They are the clients own web sites used by their employees and B2B customers. Man-in-the-middle protection is essential - but the commercial CA is unnecessary. The private CA cert is distributed by other means (e.g. CD) and preloaded in the browser.
The above approach is "self signed" in the "do it yourself sense". But I think people are talking about "self-signed" in the "not signed by anyone" sense which is implemented in SSL by signing a cert with itself. Unsigned ("self-signed") SSL certs are for testing only. There is no reason not to sign your sites. Would you provide your own RPM repository over the internet, and not bother to sign the packages? Use your own CA if you don't want to pay a commercial one.
If the general public will be using your site, and you *still* don't want to pay a commercial CA, then use http://cacert.org./ Your visitors will have to install the cacert.org CA cert first, but that is better than having to preload your CA cert and trusting you to sign *any* site.
And that is the weakness with SSL. Once you load a CA cert, you trust it to authenticate *any* website (separate policies available for email). In a less monopolistic world, any cert I download from momandpop.com, would be trusted to authenticate *.momandpop.com - but nothing else. (There is still the risk of man in the middle on first contact.) I would still trust certs from the likes of Verisign to "authenticate" total strangers (as in they had a valid credit card and controlled the sites DNS at the time of application).
Furthermore, I might want to *reduce* trust in one of the default CA certs - perhaps after reading about some scandal on slashdot. I can delete a CA, but not reduce trust. It is all or nothing.
If you do not know who you are talking to, encryption does nothing to increase your security.
Citation needed. HTTP is vulnerable to both sniffing and man-in-the-middle attacks. HTTPS with a self-signed certificate is vulnerable only to man-in-the-middle attacks, which are more difficult than sniffing.
I disagree that the message is one "that non-tech people will not have a chance of understanding." The message says: "The certificate can't be trusted because it's self-signed." Things do not get much simpler than that. Remember that self-signed certificates are the basis for man-in-the-middle attacks in https:/// sites.
Won't anyone think of the children?? :-)
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
It sounds like Mozilla did you a favor by highlighting your egregiously broken firewall.
Interested in open source engine management for your Subaru?
Just like the regulations for 'safe-driving': They should just let people do whatever they wish. If you can talk on your cellphone while driving OK, if you create an accident you should suffer the consequences and that's all (the problem is with the people that escape punishment because of the fucked up judicial system).
Wow. Just wow. Do you really not see the huge gaping flaw in that argument?? There's a reason why operating a motor vehicle on a public thoroughfare has to be considered a privilege, not a right. So let's say I'm talking on my cellphone while driving. Let's also say that I'm not a rich guy. In this little story, I have about $20 in my pocket, none in my bank account, no assets to speak of, and I live from paycheck to paycheck. And since I'm in these circumstances, my car is also not exactly in top shape. So I'm driving along talking on my cellphone, don't see the red light, and slam into the passenger side of your car as you're driving through the intersection in front of me. Bam, your wife/husband/significant other just died, you just landed in the hospital for 3 months, and all that happens to me is I get sent to jail for at most a few years. Or more likely, I died in the accident as well and you don't even get that much. Worst part is, I also didn't have insurance. My policy lapsed because I couldn't afford it.
When you're operating equipment that has a huge potential to be fatal to other persons, it absolutely has to be a privilege instead of a right. Everyone has the right to use the public road, no one has the right to operate a death machine on it.
Or perhaps I should also exercise my right to bear arms and start firing high-powered rifle shots randomly around the city? I'm sure there's no chance at all I'll ever hit someone.
There is no -1 Disagree mod. Slashdot.org/faq defines mod options. USE IT.
That proxy at your job is misconfigured.
SSL traffic needs to be passed untouched from the remote server to the client workstation. You can proxy SSL, but the bytes CANNOT be changed.
By accepting that incorrect certificate, you are opening your SSL connection to all sorts of potential attacks. The proxy server could be collecting usernames and passwords, for instance, or modifying pages. Even if you trust your employer (which is usually a bad idea), the proxy might be compromised.
I'd suggest talking to your IT department about having this fixed. It's a serious security issue.
do you fully understand the sheer stupidity of what you just said?
do you realize that the point of regulation is not to instill fear in people up to the point that they will choose freely not to drunk drive, but instead, giving the state the power to remove those drunken drivers from the road?
do you realize that the point is not punishment for skipping some rule, but *avoiding the murdering of little girls*?
god damn it. you Americans are really fucked up in the head.
Yes, but for a public user there is no difference between your self signed certificate and Harry Hacker's self signed certificate. If your application is to be used just by a finite number of user on which computers you took care of also installing your self signed certificate, then this is ok. But for a publicly accessible site, like your webmail, or your bank's internet banking application, you need a CA signed certificate, otherwise a certificate self signed by the bank looks exactly like one that a middle man can create on himself to impersonate the bank.
Firefox users are more tech-savvy than average. The decision to reduce web usability of self-signed sites could potentially reduce the number of non-tech-savvy user. This could damage Firefox, not net neutrality.
The first Certification Authorithy in this scenario is not Verisign, it is Mozilla. I decide to give my trust to Mozilla. If something like big police-iconified warnings occurs for self-signed certificates, I am free to deny my trust to them and change browser.
Besides, I think that Firefox should display a warning as big as that one also anytime you type a password field inside a non-encrypted site. Coherence.
Working to work less.
The real value would consist of actually attempting to verify the identities of those requesting a certificate. Otherwise it would all be pointless, and self-issued CAs would be just a s good.
;-)
:-)
You ask a couple of good questions, and I have no clear answers for you. I am not already on the CA business - in fact the goal of my original post was to gain further insight and hear suggestions on the matter.
Having said that, I am pretty sure it would be possible to establish some level of identity checks. The current model relies almost 100% on completing a financial transaction. Or in other words: paying for a certificate will almost 100% guarantee you a valid commercial certificate. I think a dedicated community could do better. And one thing which many enthusiasts are able to contribute to such a project, is TIME. Time spent on validating the identities of applicants.
Suggestions are welcome.
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
You can't have data security without data authenticity.
RESULT: Webmasters are all screwed by the ridiculous prices for certs that will inevitably result from the monopoly or cartel, ultimately meaning fewer web sites can afford security at all and either stop operating or just don't use security.
$14.99 is a "ridiculous" price? Really?
They are not necessary. Customers should just learn not to buy from www.amaz0n.com
While I agree about common sense, encrypted information is kinda nice I think.
You'll have that sometimes...
So why does the firefox GUI make a site with a self-signed certificate appear (to the non-technical user) less secure than a plain HTTP site?
Because it is insecure website that tries to pretend that it is secure.
Then why not just drop the lock icon in the status bar for HTTPS sites using a self-signed certificate?
...like compulsory auto insurance subsidizes the auto insurance industry.
Boo Hoo. OK, how about this: Driving is restricted to those individuals who A. have auto insurance or B. have $100,000 in escrow to cover medical costs for the mother and children they plow into while fiddling with the radio.
There ya go... Now you can stick it to those stupid insurance companies like the rebel you are.
A host is a host from coast to coast...
Unless it's down, or slow, or fails to POST!
If you look up, you will see my point hanging from the ceiling above you. Take it down, and have a second attempt at not missing it.
CAs prevent "phishing" attacks, and other attacks where a site impersonates another site. I'm saying that this risk profile does not apply to everyone, and forcing those to whom it does not apply is unfair.
And that's assuming that a CA system is even effective at this risk profile, which I also contest.
I hate printers.
If you run a self-signed certificate you still can get the man in the middle protection.
That is true, if and only if you have your users verify the certificate before accepting it. Which means you have to do things like, have them check the fingerprint of the certificate with you over the phone, or help them install a certificate authority, again verifying the CA's cert with a fingerprint, probably over the phone.
If your users are that savvy, they shouldn't be so frightened by the Firefox warning, and/or you should be able to walk them through disabling it.
And if you have a handful of clients you may install the root certificate in a controlled situation on the clients
In which case, Firefox 3 won't give you that warning, and this is a non-issue.
The "insecurity" of not using a well-known CA is only a commercial stunt.
The fact that you can say this tells me that you have no idea how SSL works.
Sigh...
Let's walk through this one more time, shall we?
- Your user types https://yoursite.com/
- A man in the middle intercepts, and sends back his own self-signed certificate, made out to look like yours.
- Your user clicks "Accept", because you've convinced him that the warning is only a "commercial stunt."
- A secure session is opened between your user and the man in the middle.
- The man in the middle intercepts and decrypts all traffic, then opens a session to you, using your real self-signed certificate, this time -- and forwards it along.
- You're now significantly less secure than plaintext HTTP, as the user will now get a nasty warning when the MITM stops intercepting their traffic.
- Additionally, you've trained them to accept self-signed certs from people who actually have real accounts. Over the next week, their Paypal account, bank information, and credit card details are stolen, all because you convinced them it's a "commercial stunt."
Don't thank God, thank a doctor!
How long do you think the price will stay at $14.99 when there is an industry that knows that there can be no further entrants?
One round of consolidation will give you a small cartel of companies that will take turns raising the price, just as any other high barrier to entry industry (oil is a good example, as is banking in many countries such as Australia).
I hate printers.
Except, honestly, people are so damn stupid that most 'attacks' are just done without any SSL at all.
If corporations are people, aren't stockholders guilty of slavery?
Why does it need to be non-profit? Why can't it just be reasonably priced?
But yeah, the answer to this problem is to create a CA that isn't expensive. What IS the procedure for starting a certificate authority?
Let's assume for a second that every website in existance used self-signed certificates.
Let's further assume Firefox stores them automatically and keeps track of them for you.
Let's also assume Firefox will give you a big red warning when one of these self-signed certificates suddenly changes.
How do you propose to start monitoring this user's internet without him/her knowing about it? Keep in mind that your man-in-the-middle attack will immediately cause several big red warnings to pop up because suddenly every website you visit has had their certificate changed (coincidence?).
Man-in-the-middle attacks are something to be wary off, but assuming you aren't ALREADY being monitored, even self-signed certificates will give you instant warning when they DO start monitoring you.
Because no.2 only provides encryption to the server that is serving that page...which could be any server that can con you into thinking that it is the correct server.
Let's say that Alice has an account at Matilda's bank. Mallory wants Alice's money. There are several attack vectors he could use.
1) Mallory spams Alice with a phishing email that convinces Alice to login to www.mati1dasbank.com (Read carefully!) to update her information. www.mati1dasbank.com resolves to Mallory's website that contains a convincing spoof of www.matildasbank.com, but with the login scripts replaced with scripts that capture and record usernames and passwords.
2) Mallory determines that Alice's ISP Ivan isn't very prompt with DNS patches and hasn't patched the recent caching-resolver vulnerability. He exploits that and convinces Ivan's DNS system that www.matildasbank.com really resolves to Mallory's webserver IP address.
Both of these vectors result in Alice talking to Mallory. If Mallory encrypts this session with a self-signed cert, Alice gets a warning and has an opportunity to detect and prevent the attack. If Mallory wants to encrypts this session with a CA provided cert (to prevent that detection) then he has to find a way to buy a certificate in an untraceable way which is non-trivial.
An encrypted conversation with Mallory is no better than an unencrypted conversation with Mallory.
I really don't support anyone that says paying through the roof for a trusted certificate is better than a self-signed certificate.
$10/year is not "through the roof" by any stretch.
This also makes rush/trial/beta setups very annoying
It's possible to route a beta to example.com/beta, but I realize most developers aren't competent enough to do that. (Relative URLs, people!)
So, next best thing, why not beta.example.com? Or staging.example.com? Or tell them not to put anything secure into it, and disable the SSL.
This isn't rocket surgery, people.
Don't thank God, thank a doctor!
Wrong.
"The communication with this site is insecure because even though data transmitted is encrypted, you don't know if some hostile 3rd party is intercepting, decrypting, recording and possibly altering data on the way. Additionally, there is no guarantee that the certificate or the web site belongs to the organization you think it belongs to."
Then you would have to change the alert box for HTTP sites in the same way:
"The communication with this site is insecure because it doesn't encrypt the data you're sending to it. Furthermore you don't know if some hostile 3rd party is intercepting, recording and possibly altering data on the way. Additionally, there is no guarantee that it's owned by the organization that it claims to belong to."
Besides, if you accept a self-signed certificate, you at least know that you're communicating with the same party with whom you communicated before. Once somebody starts to snoop a connection for which you have accepted a certificate, the certificate will change, and you'll get another warning. Code signing in Mac OS X takes advantage of this: even if VeriSign doesn't know the publisher of a new version of the program, at least the operating system knows it's the same publisher who released the last version. So we'd have to modify your proposal as follows:
"The communication with this site is insecure because even though data transmitted is encrypted, the site's certificate has changed since your last visit. This could mean that you are actually communicating with a different organization, or that some hostile 3rd party has started to intercept, decrypt, record and possibly alter data on the way."
Why does it need to be non-profit? Why can't it just be reasonably priced?
Well, no particular reason. But I personally believe that non-profit organizations are good at focusing on the customers actual needs as well as keeping the price down. The do not need to consider "profit maximization" parameters all the time, and they never deliberately try to cripple their products or devide them into a gazillion different sub-products and product types.
:-)
And "non-profit" is not free by default. It could very well be "reasonably priced", where the level of "reasonably" is determined by the actual costs of running the service - minus what ever donations and grants the operation may get from elsewhere.
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
And Grandma doesn't care about getting secure access to your blog.
She cares about reading the news, chatting about knitting on the wool forum
And making sure that her password for the wool forum doesn't get intercepted.
sending email to the grandkids
And making sure that her password for her web mail account doesn't get intercepted.
Streamlining this process or just warning Grandma will leave her with an empty bank account in no time.
Or perhaps the warning for HTTPS using a self-signed certificate could be to the effect: "This web site is not your bank." It could treat self-signed HTTPS much like web browsers treated 40- and 56-bit HTTPS before the United States eased export restrictions at the end of the Clinton administration.
http://cert.startcom.org/
StarCom offers free SSL Certificates and is included in Firefox 3 as an approved authority.
And this is actually more secure, because the permanent exception will become invalid if the certificate changes, i.e. if you're being attacked by a man-in-the-middle. How many of us use to use FF2 to connect to our self-signed administration websites and always just click "trust for this session" without verifying that the key didn't change? I know I for one actually feel more secure with FF3 because it allows you to easily make a permanent exception. FF2 had the annoying problem that if you make a permanent exception and 2 different administration websites you use had the same self-signed cert, they would conflict with each other and FF2's cert database/store would get corrupted.
"When the president does it, that means it's not illegal." - Richard M. Nixon
Problem is that your "2" doesn't exist... the way SSL (and most other secure protocols, as SSH) is designed, having encryption without authentication is pointless, because man in the middle attacks are too easy to set up.
Um, dude. Perhaps you should pay a little more attention. SSH operates via '2'. There's not even such a thing as a signed SSH key. Granted, you can use PPK to keep someone from forwarding the connection, but good luck getting the PPK on without logging in with the password once.
With SSH, the trick is to make the first connection over an internet connection that you trust, and it stores the fingerprint for future reference.
SSL sites that didn't need authentication, that just wanted password protection against cleartext sniffing on login, could trivially operate the same way.
Like it or not, there actually is a very wide range of websites that, right now, use no encryption at all, but would use SSL if it was free, and there is absolutely no way that could make them more insecure. Likewise, there are a variety of circumstances where it is easy to sniff on a user but difficult to intercept and replace their transmission.
Almost all cars can be broken into in about 60 seconds, using a slim jim on the door. However, people still lock their doors. Basically, you're arguing that it shouldn't be possible to lock a car unless it has a full-fledged car alarm, which is a rather...stupid...argument.
If corporations are people, aren't stockholders guilty of slavery?
So this is my take on all of it. To protect online commerce we need a noob-compatible "trust factor". Like some replies mention, this is achieved with the 'https' and the little lock icon (as well, now the coloured URI bar in IE). However, we also need self-signing to be a valid practice -as it was meant to be-. In this regard the error message itself is incorrect e.g. "cyote.ferrus.net uses an invalid security certificate" a self-signed certificate IS NOT INVALID. An invalid certificate is an expired/revoked/erroneous one; but I digress. The real point here is that we need two levels of trust- not a level of trust and level of distrust. There should be some way to allow a noobie user to easily identify if a certificate is signed by a CA, self-signed, or invalid. Only the third option should present itself with a horrible 5-click error message. The first option should look the "most secure", say with a lock icon and a "blue bar". The second option should have the lock icon but no "blue bar" (replace "blue bar" with whatever have you). As someone who self-signs certificates daily I had really hoped that FF3 would fix this erroneous "error" message.
If you do not care if someone can get your data, you can use plain HTTP.
If you do care, you need protection against MITM attacks - which self signed certificates do not provide.
If they would really let us be responsible for our own actions they would let us choose wether we want to pay for insurance or not.
Uusually, that's already the way it works. If you post a bond with the state in the amount of the minimum liability requirement, then you don't have to buy insurance. So you really have nothing to complain about unless you plan on causing damages and then skipping out on paying for them.
$14.99 is a "ridiculous" price? Really?
Does FF trust it? If so, maybe FF should not be trusted.
I have helped some of my clients get SSL certs. Even the $100 certs seemed way too easy to get.
Disclaimer: Web stuff is a hobby for me.
Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
MITM attacks need not impact more than one site.
It is completely possible for the MITM to just forward all packets including encrypted packets on to the intended site. The MITM would only stop the packets and pretend to be just that site. The MITM concern is really more about the this thrid party having a site that looks exactly like your bank's website, that asks for your password, and then returns an error indicating that the site is down for maintenance.
Monitoring *all* SSL connections is not generally the goal.
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
The SSL model of certificates signed by a CA is a huge contrast to the SSH model, using much of the same underlying technology, of concentrating on whether a certificate has changed.
Browsers should let you know about self-signed certificates, but they should only give you a warning the first time you visit a site with such a certificate, or if the certificate has changed. Warning you over and over again about a certificate that you have chosen to trust is a lousy model that actively discourages people from using SSL.
And, while I'm on the subject, they should probably warn you about certificate changes whether they're signed or not!
You've drawn in your conclusion a rather false and incomplete metaphor.
One issue that people seem to realize is that with a self-signed certificate is the whole man in the middle attack, it really doesn't add a great deal of security. With the DNS cache poisioning attacks, Gratitious ARP, an attacker can actually use this to his benefit. If someone is always adding the same certificate, they will just add the certificate without reviewing it. At one of my pervious companies, the mail system was available via web, and some one got personal information because the mail admins refused to spend the money on a certificate and people became so accustomed to allowing certificates because of them, that when a change occured, people just thought it was a change in certificate and they had access to the information. If you really want to secure it, don't do self-signed, build out a local PKI infrastructure that signs, and add that certificate to your browser. You have more control even, but again I wouldn't use it for external clients. As for the author, it's not Firefox alone IE7 does the same thing. The one solution for you people who want it free, is to encourage the browsers to support CACert(www.cacert.org), which uses a web of trust infrastucture
$100 a month is too expensive?! So what happens when these people who can't afford $100 a month hit a building and cause $50,000 worth of damage? Or what about hitting another car with insurance. Now the responsible person ends up subsidizing the irresponsible.
I am 28 with a clean driving record. Full coverage insurance on my new(ish) car is $1,000 a year. Minimum liability insurance is not that expensive.
I'm not not licking toads.
The servers using the private CA have a link to the key file and instructions for installing it. Since the students and faculty will be using these sites for several years and they only need to install the certificate once, I think that this is a reasonable arrangement. I certainly wouldn't want them to raise fees to cover the cost of buying certificates.
It doesn't allow me to use a real address that can be crosschecked with my phone number, because my phone service is mobile and will crosscheck to my PO Box, and they won't accept a PO Box. Why my PO Box? Because I've used my PO Box as my billing address for everything for over a decade. Why? Because I've had too much stuff vanish from my kerbside letterbox, and had several thousand dollars worth of problems from someone using stolen bills to take out a credit card in my name.
Got another alternative?
I don't agree, they have a SSL-policy to only include CA root-certificates of organisations that have had their procedures, hardware, software and organisation properly audited.
That's not really very strange. Because the browser vendor has to trust the CA to do the right thing.
If you look at CA-cert for example, they are working on making this situation better for everyone else by getting them selfs audited.
These things take time, lots of time.
_
If on the other hand you want to create your own certs, create your own organisation-root-CA. So you can import the public-key of that CA all over your organisation.
New things are always on the horizon
StartCom Certificate Authority (http://www.startssl.com/) offers free SSL certificates, and it's root certificate is included in Firefox 3.
Encryption and authentication, while certainly related concepts, should be treated more separately in the UI.
You should be able to easily -- transparently without the user really even noticing unless they pay attention -- encrypt. No matter what, and totally regardless of whether or not the other side is sufficiently authenticated and whether or not you're vulnerable to MitM.
Remember that when you have an unencrypted connection and the other side is totally unauthenticated, with even less than a self-signed and untrusted certificate, THERE IS NO WARNING. https without authentication should not look any worse, in any way, because it is no less secure.
Anyone who claims that https with an untrusted cert should produce a warning, needs to defend the policy of there not being a warning when there's no cert at all. Good fscking luck.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
God, everyone else is so stupid about car insurance. At least you reached the halfway point with 'non-profit', but you need to take it another step:
Have the state government do it. You are required to pay into a fund every year you drive. (Aka, car tags just went up by 1000%.) If your car is damaged in an auto accident that isn't your fault, the government pays for it.
And we also increase the cost of fines for such accidents, by ten times or more, payable over a few years...aka, the bad driver's insurance premium went up.
The current system is sheer nonsense. The state already collects money from drivers. The state already finds fault in car accidents and levees fines. All it needs to do is increase both of those and direct some of the money to victims of accidents.
And instead of worrying about the 'likelihood' of an accident, something that is unfair and discriminatory towards different ages, genders, and races, it will be fining people for actual crimes committed.
Independent insurance companies, of course, could still provide comprehensive coverage, for damage caused by drivers to their own vehicles or damages incurred while not driving. (Hail damage and whatnot.) Heck, they could even insure against the state-levied fines if they want.
'Mandatory insurance that everyone has that is provided by private industry' is possibly the stupidest rip-off-ist idea that has even been invented.
(Someone here is going to mention 'but what about the cost of health care'. Yeah, guess who I think should be providing that.)
If corporations are people, aren't stockholders guilty of slavery?
Your problem is a problem with ALL security measures. If they are broken you think they are safe when they aren't. This isn't just a problem with SSL.
To get SSL vulnerable to a MITM attack, you have to be giving your credentials to the other party by the same means as your secure protocol works. If you give the MD5 fingerprint via phonecall they can trust your cert and if they did likewise, you can trust them.
Unless someone has hacked your address book and given you the wrong phone number. Or hacked your SS7 switchboard or something similar.
Then again, if they hacked your OS and changed your CA signatures for IE then you're just as boned.
One of the points of SSL is non-repudiation.
Let's change the emphasis, a bit?
Only ONE of the points of SSL is non-repudiation.
So, let's throw out everything else and discourage people from providing encrypted access to their servers?
I think that's a bad idea. I've thought that a bad idea for about as long as I've been aware of the way SSL worked.
You would get the majority of the benefits simply by performing the test "is this certificate the same as the one this site provided last time?"... and really, if certificates are cheap... and given that there have been widely publicized examples of fraudulently acquired certificates (including one for a Microsoft domain on one occasion), this test should be applied regardless of whether the certificate is signed.
The only case where self-signed certificates can be secure is when you manually verify the validity of a certificate beforehand and save it in your cert store.
And if I just want to use SSL to check my email on my private domain from a public hotspot, and have the certificate stored ahead of time?
Does it work in that case? If so, isn't your first sentence incomplete?
It doesn't hurt to be nice.
The cost of barebones liability coverage is not that high assuming you have a relatively clean record
As a 20-year old male new driver with a completely clean record I can tell you that this statement is not factually accurate, unless you think paying $1,000 per year for barebones insurance when driving a Ford Ka (60 horsepower) is cheap. Personally I consider that not cheap.
Of course, I also don't have the cash on hand to self-insure, which is perhaps your point.
Unprofessional webhosters (good riddance)
Be careful. Would you want to say good riddance to every non-commercial web site? Should every web-based forum have to pay $$$ per year just to encrypt users' passwords on the way to the server?
You can also set browser.xul.error_pages.expert_bad_cert=true and Browser.ssl_override_behavior=2 to make it easy to accept self-signed certificates.
Additionally, you've trained them to accept self-signed certs from people who actually have real accounts. Over the next week, their Paypal account, bank information, and credit card details are stolen, all because you convinced them it's a "commercial stunt."
I believe it is you who trained them, by providing that warning.
The rest of us just want a trivial amount of protection for our fucking BB login, and we'd be happy if the browser didn't even mention it was SSL at all.
You're really not grasping this, are you? People complaining don't want to run damn bank sites or storefronts or anything you'd need signed SSL for.
We want to take things currently with no encryption at all and put a cheap SSL cert up there so that we're not sending cleartext passwords. Things like slashdot. Half the stuff is on shared IPs, so we couldn't even get a real cert for it, because we need a * one.
The joke is, for the longest time, browsers have provided visual clues that a site is SSL. Why are those clues not enough? Why not simply remove those clues for self-signed sites? Why popup bigass warnings?
The actual truth of the matter is that people don't use those clues. Half the time they don't look at their damn address bar at all. And because they don't use those clues, almost all phish attacks don't even bother with SSL, which sorta makes the whole 'people might be tricked by unsigned certs' argument look rather dumb.
If corporations are people, aren't stockholders guilty of slavery?
$14.99 is not a ridiculous price for one website, but when try the pricing on wildcard certificates for *.mydomain.com. And then try that pricing on when you are just trying to protect your personal data and not selling anything.
Setting up your own CA takes only a couple of minutes and lets you provide both encryption and (uni-or-bidirectional) authentication just like other CAs for any domain you like at no cost. The only expense is having to manually import the CA cert on machines where you want authentication and not just encryption.
If you are talking to somebody who poisoned the DNS cache, masquerade the site you want to talk to, using a different self-signed certificate, you are absolutely ignorant about it: your experience will be exactly the same.
Try this use case: Start a web browser that properly supports self-signed certificates. Visit an HTTPS site using a self-signed cert. You get a (minor) warning and accept the cert. Then someone starts poisoning the DNS cache using a different cert. You get a major warning that the cert for this domain has changed.
So a man-in-the-middle attack can succeed only in the case that the first visit to a site uses the poisoned cache entry.
"Obviously you don't need encryption very badly if you don't care about man-in-the-middle attacks."
Yeah I used to think that. Till I looked at certs long and hard. If you can't figure out how to let a client prove he's taking to you given the information he has available maybe you don't need to be thinking about commercial grade websites that much.
Having said that this "Warning" in FF is utterly ratarded and has to go. This is not negotialble.
If you think SSL as it's imnplemented is really that safe you should try simulating the ssl handshake with low level ssl tools so you too can see the multiple errors in almost nearly evry cert that the browesers just plain ignore so at least things like paypal actually work.
SSL may be silly but it's all we really have and whatever kiddie put this warning in spent too much time in Redmond. All I really want is a bar that gives me a security threshold - a red line or a yellow line or a green line for the three levels of security. That'll be fine thanks. And stop terrifying my customers. They're smart enough to know what's going on and I'm sick of their giggling about this FF feature.
Sorry to be in a bad mood but I have some (non ssl) web pages that work in Opera and IE and are correct but do not work in FF now. This does not help.
Also, I really still don't get why aybody would use firefox as long as Opera is as good as it is. All FF does is just plays catch-up. Incredible.
Need Mercedes parts ?
I don't know where your hackers sit, but most of mine are not in a position to bidirectionally intercept and re-transmit IP packets. Are there some people in the chain that could do that -- certainly: anyone on the same LAN segment at either end, and a handful of routers in the middle -- but that's not really a large number of potential hackers.
I agree authentication is a good thing, but it's stilly to pretend the a MiM attack is easy to implement.
And making sure that her password for the wool forum doesn't get intercepted.
She probably doesn't know or care about the possibility of anything like that happening.
She might if like a lot of Internet users, she uses the same password at her bank and the wool forum.
Perhaps the answer is to scare people even more about unencrypted comms.
Bingo. But the commercial SSL CAs don't want to acknowledge this elephant in the room.
The point is you'd have to actually implement a MiM attack, not just record the data and later mine it for useful information. You'd have to be in a position to bi-directionally intercept and retransmit IP packets along the path of the data, and have a machine in-place that can either deny transmission of the original packet or be fast enough to produce the expected reply before the original arrives.
I agree that it's important not to mistake encryption for authentication, but they are *both* useful, even individually.
This behavior means that a public web site basically can't be encrypted unless they are willing to pay an approved vendor a yearly fee for a certificate.
Ummm...no it means that the site is encrypted, Firefox just has an odd bunch of hoops for the user to jump through.
I don't agree with the new Firefox behaviour in this regards, but the author of the article is completely wrong with that statement.
A scheme where I am legally required to pay someone else to insure my and other driver's driving errors hardly seems like a good example of personal responsibility, and so unless that last line is tongue in cheek I don't know what you mean. I agree with the rest of your post though.
Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. -- Susan Ertz
There's a reason why operating a motor vehicle on a public thoroughfare has to be considered a privilege, not a right.
Yeah, because people like you think we should be proactively protected by the government.
The main argument of TFA is that FF3's warning about self signed certs is egregious.
There is not an issue about warning users; users need to be warned.
What is needed is individual warnings in a drop-down bar for individual problems with certificate issues:
*(picture of green 1's and 0's alongside a red face with a line through it) This certificate is self signed; It may not be trustworthy for identification purposes, you should only trust it for data encryption purposes.
*(picture of a green face alongside a red clock with a line through it) This certificate is out of date; it expired YYYY MM DD HH MM SS ago.
*Trusted case: (picture of a green face) This certificate identifies XYZ.com as trusted by CERTCORP.com. Your data is encrypted.
Seagoon: Shut up Eccles!
Eccles: Shut up Eccles!
This is the stupidest article I've read lately. Encryption without knowing who provides that encryption, is useless. It's basically the same as no encryption at all.
For me the question is, should self-signed certificates be allowed at all by default? I think not!
Citation needed.
Here
Not everybody who reads your comment will be prepared to buy and read the entire book just to reply. Page number please, and preferably a quotation under fair use if you can.
HTTPS with a self-signed certificate is vulnerable only to man-in-the-middle attacks, which are more difficult than sniffing.
Harder does not equal more secure, just more work for the attacker.
Exactly. If your site uses self-signed HTTPS, it is less likely to get hit than someone else's site that uses plain HTTP. It's called not being the low-hanging fruit. The problem here isn't that self-signed HTTPS has a warning but that plain HTTP has no warning.
Once he has your credit card details
Of course you wouldn't put payment on a self-signed site. Third-party payment processors such as PayPal and Google Checkout have EV SSL certificates for that. Public self-signed HTTPS is more about keeping people from stealing passwords on a non-commercial forum or wiki.
This is very bad for intranets and trust coalitions. If you run a CA that is not eligible for admission to the browsers' distributed collection, then you have a problem. Admission to the distributions requires both an expensive annual audit and persuading the browser vendor that the CA has a compelling business case _for the browser vendor_. In general this includes requiring the CA to "serve the general public" and this requirement is subjective and in the control of the browser vendor.
You either buy SSL certs from the approved list of CAs, or you do without, and you follow the verification practices of that list, whether they make any sense for the business you are in, or not. At least with Windows you can integrate private CA management into AD but this is far from adequate if you have a broader community to support.
Then we have the interesting history of the EV certificate and the self-appointed group of insiders that pushed this development.
This is a lot like the oil & steel trusts of the 19th century - isn't that ironic.
The ability of this architecture to manage multi-level CAs is also very limited. Not sure of the reasons but the scaling problems involved in managing collections of subordinate CAs and providing oversight for their policies may be involved.
Typically the browsers have moved towards supporting more flexibility rather than less, but this is a glaring if tiny exception. What would be the motivation?
If this is a move in the direction of monopoly or an old-fashioned business trust, then one should be able to make some predictions. The lists in different browsers should become identical. The bar to entry should get higher and higher. The criteria for certificates should get higher and higher, increasing costs for verification which have to be passed on to the purchasers of certificates. We're on the path for some of this but not others.
"Customers should just learn not to buy from www.amaz0n.com"
And without a trusted certificate from a third party, they'll have no way of knowing if they're talking to "amaz0n.com" when their browser says "amazon.com", after a DNS poisoning.
I agree that there are both too many CAs and the level of verification the perform is likely not enough, but getting rid of them is not the answer to everyone's problems.
That assumption is incorrect. Hell, Verisign were hacked and CA's changed.
Now a MITM attack will only work if the MITM is there poisoning your system at the very instant you are swapping credentials.
So really only an issue with your ISP or government snooping.
Insurance is a scam. Insurance companies scare consumers, telling them that the money will pay off in the long run, but if it ever did, insurance companies would be out of business.
Well, yes. A better metaphor is that car companies shouldn't be allowed to sell cars with cheap car alarms that can, in theory, be disabled in less than five minutes, and should have to either provide much more expensive ones...or they sell it with no alarms at all, like almost all cars. If they sell one with a car alarm that can be disabled in a short amount of time, they need to get the customer to do a lot of paperwork.
There's an arguable position that all car should have to come with car alarms, ones to a certain level, and that customers should be warned if they don't.
There's not really a reasonable arguments that says they can come without a car alarm, with no warning at all, but if you provide a cheap-ass one for a tiny bit more security, you have to give them all sorts of waivers to sign.
Firefox, and IE, right now, pop up enough warnings that make it seem that a web surf allowing an self-signed cert is the most dangerous thing you can do....which results in people not using any encryption at all for quite a lot of stuff. (Like, oh, the login to slashdot.)
People in favor of this talk about a 'false sense of security'. Ha. How about the false sense of insecurity browsers provide? Simply a single message 'This web site uses encryption that cannot be authenticated. Be aware it is no more secure than a standard web page.' would be more than enough. (Or, even better, no warning at all, and simply an unlocked 'lock' icon.)
If corporations are people, aren't stockholders guilty of slavery?
How long do you think the price will stay at $14.99 when there is an industry that knows that there can be no further entrants?
What? I think the price will be under $10 and stay there shortly.
One round of consolidation will give you a small cartel of companies that will take turns raising the price, just as any other high barrier to entry industry (oil is a good example, as is banking in many countries such as Australia).
Oil is a terrible example as the price of that is set by the open market and commodity traders.
You'll have that sometimes...
Yeah, because people like you think we should be proactively protected by the government.
Yes, I do believe that human life is something that should be proactively protected by the government.
I consider your right to life as being far more important than my own right to travel.
There is no -1 Disagree mod. Slashdot.org/faq defines mod options. USE IT.
You're making the assumption that "self-signed" means something to the average user. It means something to you as a technical user, but it doesn't mean diddly to grandma. She'd be lucky to understand the difference between http:/// and https://./ The furthest they're likely to get is seeing the little lock icon and thinking "I'm safe!!" The warning that comes up in firefox currently is a big sign screaming "RUN AWAY!! FIRE FIRE!!" for the average non-technical user.
yvan eht nioj
There are three factors making purely passive eavesdropping easier than a MITM attack: (1) it requires less computing power, (2) there's no way the person being eavesdropped on can notice, whereas with a MITM attack on SSL there's a risk that one of the people is actually paying attention to the certificate and will spot the attack and (3) a MITM attack affects normal network activity, so there's a risk that an administrator will notice something's wrong.
Does the proxy generate a certificate on the fly with a matching hostname? If yes, just import the proxy root certificate.
Wouldn't that, in fact, be incredibly dangerous?
If corporations are people, aren't stockholders guilty of slavery?
$14.99 is not a ridiculous price for one website, but when try the pricing on wildcard certificates for *.mydomain.com.
Ok. That'd be $199/yr. I don't consider that ridiculous for unlimited sub domains.
You'll have that sometimes...
Certificates are used to increase trust, self-signed certificates are pretty useless in that sense.
However, as was pointed out earlier, the big problem is that Firefox hasn't imported CACert root certificate in it's trusted database yet.
www.cacert.org offers a distributed verification system and service for making your own certificates using their own root certificate.
You basically need to find 3 members who validate your ID documents and place trust that you really are who you claim to be, and thus can be governmentally held responsible for any online actions you choose to do with the certificates you create. Hence the added trust. Validation can also be done via a trusted 3rd party, such as a bank manager or a notary.
having encryption without authentication is pointless, because man in the middle attacks are too easy to set up
I strongly disagree. Maybe my surfing passes through Sweden, China or USA?
If I surf encrypted sites there's quite a good chance they won't log more than some traffic from that IP to mine. Unencrypted they'll get the whole URL and cookie history. Yes, they could man-in-the-middle me, but that's likely to remain an exception for some time. For now,"encrypt first, sign later" sounds like moving in the right direction to me.
Any sufficiently advanced libertarian utopia is indistinguishable from government.
I can see the point that people make about encryption to an un-verified certificate (like a self-signed) being, potentially 'false security', but I also think the main article has a sort of point to -
Mozilla has always warned users about self-signed certificates, but I've never liked the warning. I think they are poorly worded and confusing to people, and the latest incarnation is particularly obtuse.
There is a place for self-signed certificates, I think, there just needs to be a way to add those self-signed certs to users browsers in a better fashion. Self-signed certs are perfectly safe if you have some way to verify them 'out-of-band' - that's the tricky part.
I think the ultimate answer to this problem might rely as part of a secure DNS system. We've seen from the recent DNS cache poisoning vulnerability that the current version of the DNS protocol is starting to show it's age. Perhaps DNS needs to be re-designed to include cryptographic verification of the DNS chain, so that you can know you can trust data from DNS.
If you're defining a new version of DNS anyhow, it might be a perfect opportunity to make CAs less necessary, by allowing webmasters to put their self-signed cert into their DNS records (or maybe, that might add too much data to DNS requests, but you could at least add a secure hash so that the browser could verify the cert that the web server passes it, against the DNS record for that domain). I think there might still be a place for CAs for giving additional verification (e.g. DNS would just allow you to know you were getting the right certificate for that domain, CAs can maybe do additional verifications to make sure that the organization that owns a particular domain and SSL Cert really is who they claim to be, maybe?)
Let every DNS record be its own Certificate Authority.
Yeah, and if FF popped up a message explaining that the website had presented a way to contact the same site securely in the future, although this did not confirm who they were, and ask 'if you want to store this code for the future, or just for this session, or not visit at all', that would be one thing.
Messages implying that it's somehow less secure than normal unencrypted web pages are another thing. Warning users, in big error pages and with sinister sounding warnings, when you are at least as secure as the dozens of unencrypted pages they visit every day, is just absurd.
If corporations are people, aren't stockholders guilty of slavery?
It's not like Firefox makes it impossible to access a web site with a self signed certificate. It just makes it very obvious that something is wrong with the certificate, and tells the user that he shouldn't trust it to much.
No kidding. Using self-signed SSL certificates was never really all that trustworthy, but most people weren't aware of it and so just kept on using them. Firefox 3 simply brings to light what everyone with a clue already knew:
The HTTPS security model is a barely-functional hack.
Not surprisingly, a lot of people aren't happy to find that out.
There are really only two things that can solve this:
http://outcampaign.org/
Bear in mind the three levels of security: 1) no-ssl: offers neither encryption nor authenication 2) SSL(self-signed): offers encryption 3) SSL(3rd party signed): offers both
why is that that no.2, which is a significant improvement on no.1, generates such a severe warning message?
You cannot have encryption without authentication. Encryption is defined as the confidential transfer of information only to the intended parties. If you cannot be sure that you are exchanging session encryption keys with the intended party, you might just as well be talking to the man-in-ze-middle.
-= mag =-
The problem is you've invented a world where all sites need verification. They clearly do not.
Slashdot, for example. You log in here, they have no SSL. Your password is transmitted in cleartext.
I would like my password to be encrypted so it's harder to see via traffic sniffing.
If corporations are people, aren't stockholders guilty of slavery?
The problem as I see it is that self-signed certificates are not any more or LESS secure than unencrypted http traffic. There's no reason for an additional big security warning: just treat it like normal http sites. That is, no extra visual cues, the only difference being the https in the URL. Real certificates can then have their visual cues based on their relative authenticity (automated CAs being marked as less secure, etc.) The only visual cues that should come up is big fat warnings if the certificates don't match the last time you visited a self-signed website. The only downside is amateur website creators thinking self-signed is more secure, but it doesn't hamper legitimate uses of self-signed certificates (i.e. situations where you have more direct access to clients). Plus, most amateurs should get at least a sufficient amount of training when setting up SSL to know the difference. Honestly, this would be the best way and I've never understood why there were additional warnings in browsers for something that didn't make a website any LESS secure.
The problem with this is there isn't actually anything "wrong" with those certs and they shouldn't be made to appear to have something wrong with them.
You should be able to add a trusted root to all the browsers in the company, and have the proxy generate new certs signed with your internal root cert every time someone visits a new website.
The error message is because you are doing it wrong.
No, why? It's his workplace - if he can't trust the proxy, he has other problems.
But yes, surfing on job sites is not a good idea with such a setup ;)
Firefox's new implementation of handling malformed certificates is a new bold step towards eliminating the most ridiculous concept of our time - security through obscurity. If you are at all familiar with the man in the middle attacks and phishing, you should understand that "this certificate is invalid" warning is not just a way to annoy an end-user - it indicates that the certificate can, or may have already be spoofed, and that your "secure" connection may not be secure at all.
This is equivalent to Apple users believing that there are no viruses for Mac OS or Microsoft users thinking that Vista's security model is annoying. Without realising it, people like you are making hacker's jobs a lot easier with your whining about convenience. Is it not enough that IE users already have a habit of clicking "OK" just to make "annoying" messages go away, without giving a second thought as to what the consequences may be?
If anything - you should be promoting the concept of open source certificate authorities, not pushing one of the best browsers to ignore unsigned certificates... Firefox/Mozilla's new handling of SSL is a breakthrough and if you don't think so - be my guest, ignore the warning message if you get one next time you go to your online banking website.
Bow before me, for I am root.
Just add an exception. Then, you'll get an encrypted connection to the self-signed site. What's the problem?
I agree it's annoying, but this is not 'bad' for the web or it's users, this is good. I'd like to know if I'm being connected to a potentially malicious SSL site that uses a self-signed cert. For instance, if my browser was encountering a URL hijacking attempt to a site like my bank, and it's using a bogus cert, I'd like to know. Otherwise, I'd most likely not know I'm being hijacked.
the only permanence in existence, is the impermanence of existence.
Parent advocates allowing the encrypted connection to the man in the middle, so that people will feel all warm and fuzzy. Good plan. Not.
Having an encrypted connection to a man in the middle is worse than having a plain-text connection, because at least with plain text there's a chance you won't get pwnt.
Consider: You <=> Man in the middle with self signed cert <=> Your bank
1. You lookup your bank's DNS entry.
2. DNS poisoning redirects you to man in the middle.
3. Man in the middle presents self signed certificate.
4. You create an encrypted connection to man in the middle.
5. Man in the middle decrypts your content and re-encrypts it in a separate conversation between him and your bank.
6. Bank lets him do whatever the hell he wants, because he has your password and he's using SSL.
7. You'll think you just talked to your bank.
FF3's behavior is utter crap: It's more than self-signed certs.
I've paid for a certificate. I've installed it on a website that uses Plesk, which doesn't correctly install certs.
IE doesn't complain, FF3 does. It's got something to do with the trust chain.
Don't bother posting the inevitable reply: "Google for certs + plesk". I've tried that technique. Fail.
I know: "FF3 developers are just so much smarter than the rest of us, we should just be grateful for their work." Screw you.
Here is another rant about this problem: The Firefox 3 SSL scam. This one takes the angle: how much money did the Mozilla Foundation get from big business (Verisign et al.) to kill self-signed certificates?
Note that in FF2, the dialog was perfectly clear, safe and simple. Nothing needed to be changed.
Well, lets try page 24: "And if he doesn't know who sent the message, then the message is pretty useless."
Nobody can really know who sent the message. Perhaps an attacker learned the server's root password or (gosh forbid) gained unauthorized physical access. All we can know is to some confidence level who or what sent a message. And self-signed SSL gives some confidence that one server sent all of these messages.
I know. You could use the high powered rifle to shoot drivers you deem to be a risk to you, and move the "proactive protection" the other guy is whining about from the government to you!
All you need for self-signed certificates to work is that they are accepted as long as the private key doesn't change. It's a GUI problem. You can hack wlans all you want if the browser pops up the big red warning signs when you inject a *different* cert for a site.
It's hardly a "mere" warning; it's a gigantic stop sign.
Give me a break. If they didn't do it, some idiot would get flamed because he didn't see the big stop sign, bitch about it on some blog and nobody would care.
This gigantic stop sign is called "anti-idiocy" and I agree to it. You clearly described what SSL is, but I'm sure that Joe has no idea, but he was probably told that "SSL means you're completely safe" which isn't true.
You going to tell us how you got it to work?
Because I've not been able to the two times it happened to me.
Click on the "Add an exception..." button and all the choices but cancel are greyed out. Very user-friendly that.
Kevin
And what kind of crime is "attempted murder", anyway? Do they give a Nobel Prize for "Attempted Chemistry"?
I agree that it's important not to mistake encryption for authentication, but they are *both* useful, even individually.
They are both useful individually, that's true. However, to use encryption, you have to share a key. If you haven't negotiated that key in advance, your only alternative is to authenticate the peer using a public key system like a CA. So with SSL you MUST authenticate the peer, or accept the risk that you really have no idea who you're talking to or who's listening in. Given that most people have no idea how SSL works, I don't think the average user is informed enough to accept that risk.
"Well kids, you tried your best, and you failed. The lesson is, never try."
Sorry, but honestly Firefox 3 s*cks. Plugin problems, tons of very nice unsupported addons, unwanted invasive features, makes older version profiles incompatible with the old version, privacy issues, etc.
If I wanted some idiotic silliness of IE I'd take IE, that's it. I'm just one user, but I'll firmly stick to version 2.
Which CA do you use for your SSH sessions?
I hate printers.
Mod parent up.
We trust self-signing for SSH every blessed day. Why isn't it good enough to protect our privacy on the non-commercial web?
You fail to notice one problem. Who goes to an httpS address first?
Usually when going to, for instance, a bank, a user will type in the name of the bank in the URL bar. They'll get the unencrypted website. They'll then click on the login button and get thrown to the secure site. How may of them re-authenticate the URL at that point? None.
The attack is obvious: buy a cert for a real unrelated URL, intercept the initial HTTP transaction and modify it so that all secure transactions go to your phishing site. No warning messages will be displayed, and the lock will show up just fine.
Does FF attempt to see if there's an https equivalent of the site before looking for an http version? That would most likely do significantly more good then denying self signed CAs
With regards to self signed certs, you are correct in saying that an attack on a first time connection could succeed. That is why the default for these certs should be to permanently accept: this ensures that, for a repeatedly used site, the man in the middle attack would have to be continuously done for the user to not suspect foul play.
I suppose you could just add an exception for the >site you want to access. And what happens when the 'site that you want to access' is on your local network, accessible only by you and... there are hundreds of them. Take, for example, ILO's (remote consoles to blade machines using a web page). I have to add a fscking exception for *every single one* when I first go to it. When the number of machines you have is in the 100's - that's an awful lot of clicking for something I shouldn't *need* to do. Slick.
RDP authenticates through SSL or Kerberos :P
SSH is pretty much the same as self signed certificates, but it's user base is entirely different. We have a few internal machines with a *nix on them, and i deploy their keys through Group Policy to all clients (using putty as an SSH client).
I suppose you can do the same in a *nix only environments by automating known_hosts deployment into all user profiles.
We want to take things currently with no encryption at all and put a cheap SSL cert up there so that we're not sending cleartext passwords.
I'd call $10/year for a real cert pretty damned cheap. Maybe I'm off by a factor of two -- but $20/year is still pretty damned cheap. What do you pay for hosting?
There are actually a few ways to avoid sending cleartext passwords, even over an untrusted channel, which are reasonably immune to MITM attacks -- at least, on the password itself, assuming no one did a MITM while you were creating a login.
There aren't going to be the browser clues, but an extension would solve that.
If you really can't afford $10/year, that implies you don't have a job, which implies you have a lot of time on your hands -- so you should be able to figure this out, and write the extension if needed. If you don't have that kind of time, you probably do have that kind of money. How much does Slashdot make?
Half the stuff is on shared IPs, so we couldn't even get a real cert for it
Most clients support SSL for a virtual host by now.
Why not simply remove those clues for self-signed sites? Why popup bigass warnings?
Because in the case where it is a bank site, you do want a giant fucking warning if someone's trying to MITM you.
The actual truth of the matter is that people don't use those clues. Half the time they don't look at their damn address bar at all.
I think you just answered your question -- this is exactly why there should be bigass warnings.
And because they don't use those clues, almost all phish attacks don't even bother with SSL, which sorta makes the whole 'people might be tricked by unsigned certs' argument look rather dumb.
The address bar now turns yellow -- green, for EV certs -- and sites like Paypal are hard at work training people to look for those signs. Why are you proposing to make that situation worse?
Don't thank God, thank a doctor!
Yes. You can encrypt your connection. Thats pretty worthless if you dont know with whom you exchanged your keys. Especially in the light of the DNS vulnerability or using wireless hotspots it is pretty idiotic to claim that talking to something which you dont know is to be considered private. This screams for man in the middle attacks. And You still have the option to accept the certificate - which will increase your safety. But one should point out to the user that this is something special. I find it highly irritating that a lot of companies don't pay the small amount of money for an ssl key. I work in a company where the admins are signing the ssl key for the mail server by themself (and change it often). Thats completely great. you could hack them without them noticing it, sincer everybody is so used to clicking away trhin innocent gray warning messages . On the other hand, firefox allows the definition of own ca's doesnt it?
There is a "warning," and then there is a "WARNING: YOU MUST CLICK FIVE TIMES TO SEE THIS PAGE."
You might understand the difference between the encryption and authentication uses of SSL, but most people do not. Worse, their ignorance could provide a very effective vector for social engineering attacks.
User interface warnings are for people who do not understand what they are doing. They don't know where the trouble could come from, so the software must help them. Anything that presents a likely avenue of trouble should have a strong warning in front of it.
Those who do not understand potential avenues of trouble should be encouraged to simply stay out them. Those who do understand what they are doing will also understand the warning, and know that is ok for them to proceed.
A simple bar across the top of the page with a warning that the sites identity couldn't be verified, but that the connection was still encrypted would work just fine.
Work just fine for who? It seems to me this "issue" is basically a small number of power users annoyed about having to click an "ok" button a couple times.
Build a man a fire, he's warm for one night. Set him on fire, and he's warm for the rest of his life.
A "handful of clients" can probably have the self-signed key verified manually. Probably easier to set up your own CA and give them an installer or something though.
Self-signed certs ok? net neutrality? Mr. Tuck is an embarrassment to The University of Massachusetts Lowell. Obviously they should let him post anything within the bounds of the 1st amendment and academic freedom, but I hope some professor at least makes sure he takes the appropriate classes to straighten him out about how authentication and encryption work and what net neutrality is before they hand him a diploma.
On the other hand, perhaps he's just some freshman posting junk on his university-supplied web page who had no idea it would get such scrutiny on a forum as public as slashdot. In that case, shame on Chandon Seldon for posting it to slashdot and especially shame on the editors for accepting the "story".
I know, I know, "complaining about the editors? I must be new here."
TFA seems to imply that the Mozilla policy degrades HTTPS connections down to plain HTTP - Not only does it make users less secure overall by reducing the number of encrypted connections. This isn't the case - assuming you add an exception for the particular site you are accessing over HTTPS that is using a self-signed certificate, your connection to that site is still encrypted. The only difference is that you don't have the trust element that a commercial HTTPS certificate would give you. IMHO, Mozilla is quite right to add a warning to this effect to protect the masses.
It's clear what's happening, and takes a pretty braindead wizard-type approach to importing the cert. The sky is not falling. Move along.
It's not like Firefox makes it impossible to access a web site with a self signed certificate. It just makes it very obvious that something is wrong with the certificate, and tells the user that he shouldn't trust it to much.
I am running Firefox 3.0.1 under Windows right now, and I tried to visit this web page. Firefox displayed a full-page error message that looks exactly like the error message you get when a site is down:
Yes, Firefox 3.01 did block me from accessing the website. The error message is completely unhelpful. There's no visible way around it. There's no explanation of how to resolve the problem. I was able to load the page by installing the root certificate manually, but any normal user would see this message and just think it's a broken website.
How does it benefit the world to get people to STOP using SSL?
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Many popular Linksys routers are administered by pointing your browser to an https link, typically:
https://192.168.1.1/
The router presents a self-signed cert. These routers were easily administered using early versions of Firefox. Now with Firefox 3 there's lots of confusion, with many users falling back to IE.
Turns out the situation is complicated by the fact that you can easily convince FF3 that you've got duplicate certs; to get past that you've got to do some wizard-level magic to get rid of the dups before you even get to wrestle with allowing the exception for the self-signed cert. After all that, you can indeed use FF3 to administer your router. On good days.
Does using https in this case add to security? In practice, I think the answer is, "yes, to a significant degree." I'd rather have the admin traffic to my router encrypted, even if in principle a hacker with perfect timing could have gotten "in the middle" just as I was accepting the cert.
Anyway, it's another consideration.
What you are describing is not self-signed certificates, but a self-run CA. No problems there, in fact self-run CAs are pretty much the way to get around (most) of the problems of self-signed certificates. You sound interested in this stuff; you should talk to the guys who manage it.
How dare Firefox warn me that an insecure site is insecure! They are infringing on my right to have my computer infected with malware and/or have my bank account stolen!
Which is no worse than sending an unencrypted message to the wrong person. Is it bad? Sure. Is it worse? Make your case. So far, no one has.
This is what I take issue with. First of all, I want to state that I do not belittle the value of authenticating that you have the correct recipient's key. Obviously, that is highly desirable, and I agree that it is necessary when integrity is necessary.
Now let's look at the case where integrity -- being MitM-proof -- is not necessary.
No value? You would really assign absolutely zero value to that? I can think of two ways it would add some value. Perhaps neither of these is of value to you, but if you think the UI for unauthenticated but encrypted sessions should display a warning while unauthenticated and unencrypted should not display a warning, then apparently one or both of these has negative value to you.
Remember there is a key difference between encrypted-but-unauthenticated sessions (which I admit are vulnerability to a cryptographic MitM attack) and unencrypted-and-unauthenticated sessions: the encrypted one requires a cryptographic MitM attack (whereas the unencrypted one does not). Here are some consequences to that:
The more we replace unencrypted sessions with encrypted-but-not-authenticated sessions, the more cost and risk we pile onto attackers. Sure, getting those sessions authenticated is even better. But that first step, the mere use of encryption, has benefits in itself.
The Firefox team should encourage that leap forward. But if they are not willing to do that, then they should at least stop being an obstacle.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The error message you're getting is completely different from mine:
Secure Connection Failed
www.cacert.org uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
(Error code: sec_error_unknown_issuer)
* This could be a problem with the server's configuration, or it could be someone trying to impersonate the server.
* If you have connected to this server successfully in the past, the error may be temporary, and you can try again later.
Did you install fancy plugins? :)
Self signed certificates are just like using WEP encryption on wireless. It makes people think they are safe, when in fact they are not. When people feel safe, they are easier to persuade to give out details they otherwise would not.
In this sense using self-signed certificate outside of closed communities is provably worse than using no SSL at all. It luls people in a false sense of security, which is the worst thing that can happen.
Yes, it is true that SSL can be used for encryption only, without verification and proof of authenticy. I could just as well use truck to commute every day, without using it's cargo hold, but nobody would ever say that is a good or useful idea(*).
(*) SUV owners might disagree, but they are becoming a dying breed anyway.
There is almost no added security from #2 compared to #1. But Firefox could simply render the page like a normal, non-encrypted one. That means, no lock, no yellow bar and no security warning.
Rethinking email
MitM attacks don't have to be at some point physically between you and your intended destination... just logically.
If I can poison your ISP's DNS cache with a bad resolution for www.your_bank.com and you accept my self-signed cert then I own you.
If I can get you to believe that phishing email that I sent ("Urgent Action required! Update your security details at www.y0ur_bank.com") and you accept my self-signed cert, then I also own you.
Neither of these attacks require me to be on a network segment between you and your ISP,but are indeed MitM attacks.
If you don't verify a certificate against something, it's utterly useless against Man-In-The-Middle attacks.
I take a server, generate my own cert and key, and present myself as that server. I then take your data, and forward it to the server, and forward the response to you.
This leaves me with all of the data, making SSL worthless.
So, yeah, I'm going to go with "moron" on this one.
They MIGHT use encryption if SSL was free and issued on a total wildcard basis.
A huge proportion of the web doesn't run on dedicated IPs.
You seem to not understand insurance. The ENTIRE point is so that people like you subsidize people who get into a wreck a week.
That and take the unknown risk of a car accident (in financial terms) and package it into a nice monthly fee.
Compulsory insurance means that you pay much less, because the pool of risk is much larger. And realistically everyone who drives needs auto insurance because accidents can be very expensive.
My office just got hit with a rogue-DNS oriented MITM attack. Enhancing usability in this manner makes you SERIOUSLY vulnerable to such attacks. Firefox 3's behavior in this regard saved our asses, because it's what alerted us to the problem in the first place. This is no joke.
The proposed solution in the referenced livejournal link is reasonable. But in no way should you make it terribly easy, because doing so would be a lurking disaster.
... all bullshit.
Mozilla has an honest, vested interest in protecting the credibility of the little TSL (artist-formerly known as SSL and/or HTTPS) 'lock icon' in their Firefox browser.
Mozilla wants this icon to mean "by the best of our abilities, the Mozilla Foundation believe that the website you are visiting is who it claims it is."
Allowing anyone to slap the lock icon on their site subverts the credibility, and hence utilty, of the lock icon.
The browsers are so happy to make the URL bar green when it is a secure site.
Then make it green when the site is verified and encryped.
Make it blue when it's only encryped.
and make it red when it is not encryped.
And make it yellow when only something on the page is encryped.
create your own CA and tell your customers to import the CA by clicking here (before putting them in ssl mode)
How are your customers going to know the cert comes from you? As long as you're serving it from a known address instead of personally installing it your clients' browsers, couldn't the man-in-the-middle that you're so worried about just replace your cert with his own? Or am I missing something?
There is a significant difference when the eavesdropper isn't targeting anyone specifically but throwing their net wide in the hope of catching something interesting. If (almost) all net traffic were routinely encrypted, it would be much harder. As it is, encryption rather marks you as an interesting target.
Don't be silly. Without a proper certificate one can sit right between you and amazon.com and rip you off. Don't confuse cheap lookalikes like amaz0n.com or variations with professionally made man in the middle attacks where you will really go to www.amazon.com but you will actually talk to someone else.It seems to be a lot of misconception and ignorance about certificates today. Also, do not forget that CA's bureaucracy is partially justified, think that their role is actually to grant certificates to a valid and verified entity, not just anyone.Same goes for entering the market, you would not want your average Chinese to open his own CA and then grant certificates without properly verifying who's behind them, right ? A certificate is ultimately an electronic ID for a service, and as with any ID, they must be granted under a more strict rule, or otherwise anyone will be printing his own driver license or ID card at home - problem being that one could easily impersonate anyone.
Right, it doesn't need to claim the connection is to a known party, just use encryption to keep the ISP and everyone else from sniffing.
This prevents those sites from using HTTPS, as it makes entering them pretty hard and obvious.
And preventing them from using https does what exactly? The users don't get that great big warning screen that they supposedly require. There's just a missing padlock in the status bar. It's hard to justify a full screen alert with a multistage exception procedure when it's this easy to go around.
Mission solved.
Accomplished. It's mission accomplished and problem solved. Except it isn't.
Those are my principles. If you don't like them I have others. -Groucho Marx
Well, no, you can't. If you share the key used to sign your certificates out-of-band with your users so that they can trust you as a CA, then you can get MITM protection, but then you aren't "self-signed" as the term is usually used (particularly, a browser with your CA key installed, the only way you get MITM protection, won't warn that your page is protected only by a "self-signed" certificate), you have a regular CA-signed certificate where the CA happens to be under your control.
"It damages the basic principle of equality among web participants." When the web participants are certificate authorities, I don't *want* equality. I want one or two well established and trusted sources. If Verisign and Joe's Cert Auth had the same level of implicit trust, we would be in trouble.
Problem is that your "2" doesn't exist... the way SSL (and most other secure protocols, as SSH) is designed, having encryption without authentication is pointless, because man in the middle attacks are too easy to set up.
For small community websites, 2 could easily exist. Simply pass the certificate through a secure channel and warn if it changes. Blocks out ISPs and prevents any MitM attacks.
Earlier comment reads as follows: "I second this complaint."
Nothing else.
The copied post is a perfect example. The person agreed with what the critics laid out but what happened? -1 Troll. What a joke. Who is modding these boards? I guess the message is, don't disagree with the TROLLS that mod these posts. Follow the mantra to the letter or be mocked.
This site is becoming a straight up joke.
I'll try anything once. Twice if it tastes good
Yes, funny isn't it. I read slashdot for years, I develop web services since...1997? I use firefox for...mmmh 3 years and I have never touched this allowed list. I never had to.
Now...Let's imagine what would be the reaction of the lambda user. They'll think that those uncrypted server are more secure than those crypted ones with a self signed key. And this "allow" or exception feature is a very dangerous security breach.
"Things do not get much simpler than that."
um. right. You're not serious, are you?
To a non-tech person, a certificate is what you get after swimming 10 lengths, and signing is what happens to books, by authors. "The certificate can't be trusted because it's self-signed." means absolutely NOTHING to a non-tech person. They'll be sitting there thinking "what on earth does self-signed mean? Is that good?"
Even a message saying: "Most secure (https) websites have a "signed certificate" to prove who they are. This website's certificate was signed by themselves, and thus we cannot be sure of their identity" is too complicated for the lowest common denominator.
Something really basic would be better, like: "This website has given us no proof of who they really are. All secure (https) websites are encrypted to protect against eavesdropping, and the vast majority of them also provide proof of their identity. This one is encrypted, but there's no way we can ensure that they are who they say they are."
So the difference between a "professional webhoster" and an "unprofessional webhoster" is a 15 dollar certificate?
plaintext = possibility of sniffing + possibility of unknown identity on the receiving end
self-signed https = possibility of unknown identity on the receiving end
therefore, self-signed https more secure than plaintext.
OH NO!!! It's so hard to apt-get install ettercap!!!!!!!!!!!!!!!!!!!! Security through obscurity. And not in a good way (security through obscurity is useless as a purely defensive measure, especially when it's your only one).
The number of people who mis-understand SSL on Slashdot is appalling; I keep seeing these threads pop up time and time again. Anyone who thinks self-signed certificates are a good tool for obtaining any form of security beyond that which is afforded by normal plain-text means, in a real, practical environment, does NOT understand SSL. At all. Get off of Slashdot.
You got it wrong.
plaintext = possibility of sniffing + possibility of unknown identity on the receiving end
self-signed https = possibility of sniffing + possibility of unknown identity on the receiving end + false perception of secure comms
Therefore, self-signed https is less secure than plaintext.
So which of you complainants is going to be the first to write a gnupg support patch for Firefox?
That makes about as much sense as saying that you shouldn't bother to wear a seatbelt, because in a subset of car accidents you will die anyway.
Building a better backup.
Zettabyte Storage
Haha, sorry but I'm not American. I don't want the government to instill fear in people, I want them to let the people learn by themselves what it means to be responsible. If you look on sites like notalwaysright.com (it's the first that comes to mind but I see examples like those everyday) you will see that humans are losing their common sense at a rapidly growing speed because of all the "proactive protection" imposed by the government. Whatever security and safety measures we put in place there will always be someone stupid enough to harm him/her or someone else. I'm not going to talk about willfully doing harm because you can't stop with regulations anyway.
ics
"and all that happens to me is I get sent to jail for at most a few years"
That is my point exactly. Stupid stuff like that should be punished more harshly. People would maybe then learn not to drive carelessly.
"Worst part is, I also didn't have insurance. My policy lapsed because I couldn't afford it."
To be honest, when someone important to me dies in a car accident I really don't care about the fucking money. Of course financial aid for hospitalization etc. is welcome in such cases but those could be provided by the state (or should be).
Getting money from the guilty guy is just a byproduct of capitalism. In my opinion anyone who thinks he deserves financial compensation proportional to the loss (s)he suffered (friend, relative, family) does not deserve any kind of help. That's just greed, nothing else.
Of course I will be flamed for this. Some will call me a communist or fascist, others will think I'm a sociopath. But just so you know I wouldn't take money if someone dear to me would die because of someone else. I would want revenge although I probably won't do anything about it anyway but would be happy the more jail he/she would get.
ics
ssh is vulnerable unless you set up the fingerprint of the host you're talking to beforehand.
How many times have you just ignored this warning and allowed ssh to continue?
Warning: Permanently added 'foo.bar.com,23.227.17.89' (RSA) to the list of known hosts.
If you're allowing that, it's trivial for someone to perform a man-in-the-middle attack on your connection. You have no idea if you've accepted the host's actual key or the hijacker's key.
A few years ago I griped at mozilla about this argument (about cacert.org's lack of support in fact). I made the suggestion that 'trust' is a community thing and shouldn't be left with any one individual/company. I proposed that a browser could/should a) display a particular websites's trustworthiness (and it includes it's CA) and b) a method for a user to give a site the thumbs up or thumbs down, just like any voting scenario we have. It is an easy system to implement and it would quickly reflect on bad CA's who do not check their client's certification (if at all possible).
You're still setting up a straw man argument to promote the authentication function of SSL. I totally understand what you're saying, we all get that. But you obviously don't have any real world experience on the ins and outs of this. Try to understand that there are times (many times in my experience) where you want SSL and don't care about a CA or getting authentication.
For one, *I don't CARE* about MITM attacks - they are 10000 times harder to pull off than basic wireless or ethernet snooping at a hotel, Internet cafe, or on a LAN. I am *WAY* more concerned with somebody sitting on the wire passively listening on a peer node than somebody with network infrastructure access and a server plugged in that is statefully monitoring all traffic and attacking HTTP SSL traffic by creating duplicate certs on the fly. That is what I use a lot of SSL for, to get OUT of a known hostile local environment, not to prevent a much harder MITM attack.
I should be able to use this perfectly valid and common purpose of SSL without excessive annoyances. Some of these cert errors aren't even bypassable in Fx3, which is even more ridiculous. The browser should inform the user as to the status of the certificate as best and unobtrusively as it can. If I wanted to be treated like I'm stupid and prevented from doing things that I want to do because a browser thinks it would be better that way, then I'd use IE.
If you're looking to worry about obscure attacks then I'm sure you modify your list of Certificate Authority's, removing ones who don't live up to your own personal levels of validation? Oh you don't? Do you check the signatures on your browser every time you install it or update it to make sure the upstream source wasn't tampered with? Do you check your keyboard plug every time you sit down at your desktop to make sure there isn't a logger on it? Do you cover your keyboard everytime you enter your password to make sure nobody is watching? No? There are thousands of potential vulnerabilities that exist every time you use your computer, let SSL do (one of) its job(s) and quit making it out like it's worthless without authentication - it's not. Security is effective only in layers; SSL is just one of those layers. As an intelligent user and/or sys admin I should be able to choose the security cost vs. risk ratio that I am willing to live with. Browsers making those decisions for me is a problem.
No, you missed the point.
The point is that encryption without certification provides really useful functionality and should not be discouraged.
Encryption with certification IS better (I am not claiming that it is not), though not perfect either. The owners of www.y0ur_bank.com can still obtain certificates, and this has happened in the past.
What's the deal I love the new method that FF3 uses, using snake-oil and self-signed certificates for quite a few things it's lovely to be presented with a box which in a few clicks can add a permanent exception for this specific certificate.
Ok perhaps if your not quite clued up on things it's confusing, but it's only there to fix the legion of morons who would click though the previous warning and go shopping on a pished site.
I think changing the rules in the middle of the game is something Hit^H^H^H George W Bush would do :P
Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
Why? because if ( the system ) wants to notify a nearly-fatal "error" just say that:
"there is a grave issue here: blah blah blah...." and don't let the user continue
but here we just have a "self signed certified" situation. What is the no-brainer and correct ( UI science ) solution?:
say the truth, in simple words let the user choose what to do and provide a link to get more info if he want it
Example:
"This site is attempting to use a self signed certificate to provide encryption and authentication. Please read carefully the following alternatives and choose one:
[ ] See more info about self-signed certification
[ ] Cancel navegation to "https://blah.blah.com"
[ ] Continue to "https://blah.blah.com"
[ ] Continue to "https://blah.blah.com" and don't show this message again ( Firefox will remember blah.blah.com certificate )
And voila,, ready! The user is informed about the situation and he can decide what to do or get more info if he wants it. But if he wants to continue browsing his "dangerous" site without annoying freaking UI artifacts LET THEM DO IT!!!
Who put in Firefox team minds that they must be the SSL superheroes that should keep we ( stupid and ignorant ) users away of the SSL bad guys in the wild wild internet?
That is my point exactly. Stupid stuff like that should be punished more harshly. People would maybe then learn not to drive carelessly.
That doesn't address the issue.
First, there's no punishment sufficiently harsh for killing another human, other than the death penalty.
Second, there's automobile accidents where people die and no one is really at fault. It's just simply an accident. For whatever reason, it couldn't be avoided. Maybe I run into a pothole which causes me to lose control of my car, which then causes me to crash head-on into your car. Or maybe it's a dog. Or maybe one of my brand new tires was a lemon and I had a blow-out. There's just no way to always pin the blame on someone. So what you do is eliminate the most high-risk drivers to keep it as safe as possible. That's the whole idea of "driving is a privilege". You're in control of a machine that could at any moment cause the death of another person. In order to have the privilege to operate that machine, you need to qualify yourself as being capable of maintaining control even in many unavoidable emergency situations. (Obviously America doesn't do as good a job of weeding out the incompetent as many countries do, but that's another topic for discussion.) And for those times when you just can't, there's insurance.
There is no -1 Disagree mod. Slashdot.org/faq defines mod options. USE IT.
Learn to read, Anonymous Moron. His choices are 1) pay money, 2) pay money, 3) go unsupported. Your suggestion will not work for someone with a simple shared hosting account like his.
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
There is no punishment harsh enough that makes people feel better after losing a family member. But that is not the real problem since you can't take care of every person in the world. All we can do is make sure that on the whole less people die. Regulating each possible situation that may arise while driving is naive at best.
Now, how are insurances helping to weed out the high risk drivers? You just obligate dangerous people to pay in advance for the damage they will cause. And usually the insurance they pay doesn't cover a single repair cost. The money actually comes more from good drivers too since there are probably more of those out there. Also, insurance covers only some of the possible accidents and certainly not moral damages that would be payed in some extreme cases.
And how are they helping against honest accidents? Sure, the repair costs but then why couldn't the government just pay for true accidents and be asked for a 0.5$ more in taxes or something? It's more direct and cost effective.
ics
For one, *I don't CARE* about MITM attacks - they are 10000 times harder to pull off than basic wireless or ethernet snooping at a hotel, Internet cafe, or on a LAN.
Maybe so, but I don't have to, because someone else already has. Downloading Wireshark and downloading Airpwn are equally trivial. Implementing Wireshark is probably harder than implementing Airpwn, but that's really irrelevant.
And if your attitude becomes common, how soon before the same kinds of automated passive attacks are replaced with automated active attacks?
If I wanted to be treated like I'm stupid and prevented from doing things that I want to do because a browser thinks it would be better that way, then I'd use IE.
Major difference: IE won't give you a choice. If you feel so strongly about this behavior in Firefox, go patch it. Or, if you're not a developer (or feeling particularly lazy), file a bug asking for the ability to turn this off, or troll around looking for people willing to fork the browser.
For what it's worth, even SSH behaves like this. If you SSH to a host which is unknown, you'll get a big ugly warning -- and it will then keep track of that host key. If you SSH to a host whose key has changed, you will get a GIANT ERROR, which in BIG SCARY CAPS tells you that it's possible someone's intercepting your traffic RIGHT NOW OMG!
And there is no way to override it short of removing the key manually from the config file -- which is a good deal harder than four clicks.
I would think SSH is the kind of tool power users would be using for themselves. It's the kind of place you would expect people to be well-educated about this sort of thing, and where you'd expect people to not want their decisions made for them.
But they chose to make it difficult to be insecure.
Do you check the signatures on your browser every time you install it or update it to make sure the upstream source wasn't tampered with?
Actually, yes. Specifically, apt uses GPG to check them. Every install, every update -- of every app on the system. I therefore open myself up to a MITM exactly once -- when I download the install CD.
Do you check your keyboard plug every time you sit down at your desktop to make sure there isn't a logger on it?
Actually, I carry my keyboard with me. Not for security reasons, but it does kind of make this moot.
Do you cover your keyboard everytime you enter your password to make sure nobody is watching?
No. I do, however, use Dvorak, and type extremely fast. Someone would have to be watching very carefully, or recording it to play back at a slower speed. And that password is only used locally -- the passwords I use remotely, I mostly have my browser memorize, or they're keys instead of passwords -- so they would have to steal my machine in order to do it.
In the case of my laptop, they would also have to steal my USB key, or they'd have to very, very quickly perform a cold-boot exploit.
There are thousands of potential vulnerabilities that exist every time you use your computer
I don't see that as a reason to introduce more.
quit making it out like it's worthless without authentication - it's not.
Actually, it kind of is. Without authentication, it is security through obscurity -- you're basically praying that no one who is capable of sniffing your packets realizes that they could probably alter them, too.
Now, by some arguments, it's not completely useless. After all, neither is the "two-factor authentication" employed by most banks -- since it is theoretically possible that someone would collect your password, but not the answer to your security question.
But the payoff is so low, at this point, that I don't see why you'd bother -- and I think it's dangerous to support it at all, because it provides a false sense of security.
Don't thank God, thank a doctor!
There are two different issues being tackled with SSL encryption. The first is encrypting the data packets between the browser and the server, which doesn't require a Certificate Authority. The second is confirming the identity of the site, which does require an authority that can verify the existence of the entity in question.
In the case of a self-issued certificate, it would be a lot easier if Firefox and other browser simply said, "Data between you and the server will be encrypted, but the site's identity cannot be vouched for. Sensitive data should not be submitted to this site. Do you want to continue?" as opposed hyperbole about misconfigured servers, end-of-the-world psuedo-hack warnings, etc.
By the definition of Terrorist in your sig, I was a terrorist in the minds of my athletic opponents back in high school, and Almighty God is a terrorist in the minds of many followers of the western religions including and descending from Judaism. Oh, throw great white sharks in as terrorists too, as being killed by Al Qaeda holds about the same probability as being attacked by Jaws. Yet in this case, the fear of Jaws is likely much greater than that of Al Qaeda.
Phishers.
If you don't see a warning for self signred certifcates I can make a ssl website identical to citibank and pound users up the ass.
Stupid stupid article.
I bet the opinions demonstrated in the 1.759 million characters of text in this /. thread are going to convince Mozilla to change their mind and redo the code.
very well said. It's the discrepancy between the "masses" and the "informed". It's brilliant, and very responsible of the FF team to make this happen to the masses, and for all of us "informed", in one way or another, we just re-install our company wide CA and we're off again.
I'd rather my mum gets told by FF to distrust some site, than instead her happily inputting her personal details to some site that's a bit flakey. That's the problem of having to protect such a large range of users. All my clients and staff are easily informed about a new CA certificate (mine) change (+url). Doing that to millions of unsuspecting users is not really that easy.
The surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. BW.
E-mail the cert to all valid users with instructions on how to put the cert into the cert db for firefox and ie.
When you consider that it requires no more effort on the CA's part than the $14.99 cert, it's an absolutely outrageous mark-up.
And yet, phishing is rampant. Perhaps because people "know" that if the site was up to no good, there would be that big untrusted site/bad certificate thingy.
When you say 'good riddance to unprofessional webhosters'; you are not saying 'good riddance' to low-quality webhosters; you are saying good riddance to non-profit sites in general.
There is nothing wrong or invalid with a self-signed certificate.
The expectation is the user will validate (or reject) the certificate without the benefit of a for-pay CA.
If they accept it, they add it to the database, and the browser should recognize it as "known" in the future.
Just like your SSH client warns you the first time you connect to a new host.
It would be ridiculous for your SSH client to bring up a red "SECURITY ALERT" dialog, and demand you manually add an "exception" to your .ssh/hosts file, to allow the new host to be easily registered.
As an online discussion gets more and more posts, the probability of a reference to Godwin's law approaches one.
http://cacert.org/
Very expensive, yes.
I am really not a fan of firefox, but this it does right. The original author did not put in a lot of research nor a lot of thought.
> 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.
Okay so as a hacker I redirect my banks website to my own website, encrypted. No warning pops up on the users screen that the certificate is invalid yet. On the webpage, I tell the user that their bank account has been frozen, and to call a given phone number. The user does, and I get all of his details.
99% of people who are on the web are NOT security experts. They're also WAY more likely to ignore subtle warnings about the identity of a site being questionable. For the average person (not the average /. subscriber) a subtle warning is completely futile in providing any security at all. The new SSL handling in FF3 is going to help....a LOT, imho.
In the overall scheme of things, which is better:
1) Having Joe User think a website is down where it isn't, which will only happen in a VERY small percentage of cases, or
2) Having Joe User provide his credit card info and SSN to a site he thinks is ok because he doesn't know any better?
One must remember that FF is no longer used only by net-savvy techie guys anymore. It has a WAY broader userbase now, and these changes are going to protect a LOT of people.
SSL without Entity Authentication is of no value.
Comment removed based on user account deletion
You raise a good point, but don't forget that in order to tell the user his bank account was frozen, he most likely would have had to input data. Otherwise, he would likely be wondering the bank was telling him his account was frozen without even entering his username.
This website has given us no proof of who they really are. All secure (https) websites are encrypted to protect against eavesdropping, and the vast majority of them also provide proof of their identity. This one is encrypted, but there's no way we can ensure that they are who they say they are.
I would add:
Unless you know beyond any doubt that this website is the one you think it is, do not proceed. But if you do know, click _here_ and add an exception, so you won't see this message again.
Now, all we have to do is send the patch to mozilla... :-) Do you know if there is an already open bug?
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
What is your admin smoking? Do they really want your bank account number and password? They've installed a Man-in-the-Middle attack on their main network. Either they really don't trust the employees, or the admin who set it up wants to be rich after he leaves the company.
No, I mean, trusting the proxy would present all SSL sites as authenticated...even ones that weren't, or were clearly the wrong name, or expired, or even revoked.
If corporations are people, aren't stockholders guilty of slavery?
There are actually a few ways to avoid sending cleartext passwords, even over an untrusted channel, which are reasonably immune to MITM attacks -- at least, on the password itself, assuming no one did a MITM while you were creating a login.
Not without Javascript or HTTP auth.
If you really can't afford $10/year, that implies you don't have a job, which implies you have a lot of time on your hands -- so you should be able to figure this out, and write the extension if needed. If you don't have that kind of time, you probably do have that kind of money. How much does Slashdot make?
Aaaaaand....cue the personal attacks and insinuations.
As it so happens, I do have a job, and part of that job is to run an web server with some SSL storefronts. It also runs a lot of Joomla community sites that have a slight amount of security would be nice.
Most clients support SSL for a virtual host [wikipedia.org] by now.
'Most clients', of course, not including IE6 or IE7 on XP. Which by themselves occupy >50% of the web browsing traffic. (And while half the remainer might be using more advanced browsers, the other half is using less.)
Because in the case where it is a bank site, you do want a giant fucking warning if someone's trying to MITM you.
If someone is trying to MitM your bank, you know what he'll do? He just won't use SSL.
The address bar now turns yellow -- green, for EV certs -- and sites like Paypal are hard at work training people to look for those signs. Why are you proposing to make that situation worse?
What the hell are you talking about? I said to not provide the clues for self-signed certs. People who know about the clues thus won't be fooled. People who don't know about the clues are already fooled by simply not using SSL.
I swear, people like you are so goddamn annoying. Everyone pushing for not having big warnings about self-signed certs is fine if browsers don't put up lock icons and green bars and everything, and we've been saying this from the start. It's fine if there's no indication at all it's an encrypted connection.
All your yammering about people being 'fooled' requires people somehow being smart enough to figure out they're on encrypted connection, and yet dumb enough to not realize it's not signed by a trusted authority. So you imagine a world where web browsers treat CA-signed and self-signed certs exactly the same, despite that being obviously fucking stupid and not what anyone is suggesting. Web browsers can indicate it however they want, or not at all, as long as they don't run around implying it's somehow less secure, and requires more work, than plaintext browsing.
We are simply suggesting that we be allowed to encrypt web pages, with no authentication, if we so choose, without bigass warnings popping up scaring everyone, so people can't trivially snoop on a connection and get passwords. (Which, despite what people seem to think, actually is a hell of a lot easier than MitMing a connection.) That is all.
If corporations are people, aren't stockholders guilty of slavery?
In such a setup, it would be the SSL Proxy's job to make sure that the "real" certificate is right. The user never sees it.
Well, the whole thing is set up stupidly in the first place.
The entire concept of secured-from-the-start SSL on another port was incredibly stupid. It happened with POP3, IMAP, HTTP, etc, and has caused nothing but problems.
Writing all protocols where you first connect in plaintext, and then switch to an encrypted connection, would have been infinitely more sensible.
Especially since, if we'd done it then, we could have had a OOB character defined to do that and everyone could have done it the same way. I.e, it should have been part of the 'telnet' protocol.(Yes, yes, that's not actually the 'telnet' protocol, but you know what I mean.)
Everyone's switching over now, with things like STARTTLS and the new virtual hosts for HTTPS (I believe that starts unencrypted and sends the hostname, and then flips to encrypted, but I could be wrong.), but there are always going to be clients out there that can either speak plaintext or SSL, not start plaintext and switch, so the SSL ports will be around for a long time.
Hell, I still have to run a damn encrypted 'smtps' port on 465 on my mail server, for Outlook Express, because it can't connect to the standard submission port and send STARTTLS.
If corporations are people, aren't stockholders guilty of slavery?
Not without Javascript or HTTP auth.
Right. Why is this a problem, again?
Aaaaaand....cue the personal attacks and insinuations.
This isn't personal. Minimum wage in this country is more than enough to afford $15/year for a cheap certificate. As an expense for a business, it should be minimal.
For the amount of time and effort you've put into arguing with me, at a decent wage, you could probably afford two certificates, or the same certificate for two years.
You haven't actually provided a counterargument -- you've just refused to answer it as a personal attack.
It's fine if there's no indication at all it's an encrypted connection.
Seems outside the scope of SSL. Or rather, under that scope. And as you stated above, you already have two options: HTTP auth and Javascript.
All your yammering about people being 'fooled' requires people somehow being smart enough to figure out they're on encrypted connection, and yet dumb enough to not realize it's not signed by a trusted authority.
For over a decade, there has been a lock icon in the taskbar, and https in the URL -- and we've been training users to look for these signs. A green address bar is nice, yes, but what you're proposing is that we completely retrain users to look for completely different clues for "this is an encrypted connection that I trust" and "this is just some random encrypted connection".
That, or you're proposing that we hide the crypto from users entirely -- which seems just as heavy-handed as throwing up gigantic warnings. So much for wanting choice.
(Which, despite what people seem to think, actually is a hell of a lot easier than MitMing a connection.)
Seems you didn't actually have a counter for my airpwn link.
Give me one situation where someone would "trivially snoop on a connection" without also being able to trivially run an SSL MITM attack, and trivially snoop on your wish-it-was-SSL connection.
Don't thank God, thank a doctor!
I disagree. With STARTTLS, it's much easier for a misconfigured client to send credentials in the clear. Server policy may prevent those credentials from being honored before TLS establishment, but by then they've already been exposed.
I'm not sure what problems you think having TLS-wrapped port designations causes.
The client uses an extended TLS Hello that contains the desired hostname. It's not encrypted, since it precedes key establishment. As far as I know, this is not in wide deployment as of yet.
Good point. Maybe you could have it look like he is still logged in?
I disagree. With STARTTLS, it's much easier for a misconfigured client to send credentials in the clear. Server policy may prevent those credentials from being honored before TLS establishment, but by then they've already been exposed.
Yes, it's easy for a misconfigured client to do almost anything. I mean, type the wrong domain name in, and who knows where it will send your credentials!
However, if the system had been set up to switch automatically from the start, correctly configured servers and any clients that supported SSL could switch automatically. Without any prompting or 'configuration'. If the client and server support SSL, they'd negotiate it in the connection. If one of them didn't...well, you're insecure no matter how you're configured.
Whereas, with a two port system, all clients are going to default to the unencrypted port, which means they will have no security at all. Which in actual fact is a good 95% of POP3 and IMAP users out there. They selected POP3 or IMAP, and got port 110 or 143, and that's it. (1)
And, of course, nothing would stop clients from offering a 'refuse to send credentials until encrypted' toggle. Although a more logical default, especially for mail clients, would just be to store a cert, for each connection, when they get it, and warn if it changes.
I'm not sure what problems you think having TLS-wrapped port designations causes.
Well, um, there's exactly what we're talking about, with HTTPS connections.
1) Of course, a lot of server scramble the login, but reading other people here talking about unauthenticated HTTPS, we are apparently required to assume there are dozens of MitM attempting to hijack our connections, and any 'security' that doesn't protect against that is no security at all and not worth doing. So obviously scrambled passwords are a scam...MitM can just hijack your IMAP connection, or whatever, and keep it open forever.
If corporations are people, aren't stockholders guilty of slavery?
True, but domain name, unlike TLS/STARTTLS settings in a client, is relatively hard for Joe User to get wrong. And if he succeeds, the eavesdropper doesn't automatically know what host the credentials are for.
Unless the server isn't even listening on the cleartext port, which is how I configure my systems. This way the client can't establish a connection to the non-SSL version, let alone send credentials or other data in the clear. This wouldn't be possible in the switching system you advocate for.
Furthermore, a switching system entangles application protocols with the constantly mutating TLS, which would make maintenance of both more difficult.
There'd be no harm in having such a toggle for clients, but as server admin, I don't get to make sure it's set. So I prefer a method where I can keep the client from talking to the server unless SSL is already negotiated.
An alternative to the status quo that might satisfy both of us would be to do away with cleartext IMAP and POP altogether. But for services like SMTP, HTTP, and LDAP, a parallel cleartext version is less dispensible.
Certificates change regularly for legitimate reasons. I see no reason to confuse users by alerting them when this happens.
Yes, what specific problem are you talking about? HTTP is for anything that doesn't require a secret (mod Digest auth); HTTPS is for everything else. What's the problem?
If you assume otherwise, you get what you deserve.
This isn't personal. Minimum wage in this country is more than enough to afford $15/year for a cheap certificate. As an expense for a business, it should be minimal.
And I notice you completely ignored the 'And we don't have infinite IPs either' point when I demonstrated that the majority of web browsers do not support them.
IP addresses are not free.
And I've already pointed out we're not talking about businesses. Online businesses obviously need authentication. A guy who can barely afford godaddy to run his joomla discussion board does not.
Seems outside the scope of SSL. Or rather, under that scope. And as you stated above, you already have two options: HTTP auth and Javascript.
Yes, and I use Javascript.
That doesn't mean that I can't say 'I wish the web browser would encode this password using the encryption built in, instead of something written in this annoying language'. Public key encryption in Javascript is incredibly annoying.
HTTP auth would be an option, and this is actually what it's designed for, if it wasn't the ignored step-child of web browsers. It's a frickin giant dialog box, entirely breaking the paradigm of the web. Why they can't give a login bar along the top of the page and print the 'error' page under it, I don't know.
That, or you're proposing that we hide the crypto from users entirely -- which seems just as heavy-handed as throwing up gigantic warnings. So much for wanting choice.
How the heck is that 'heavy handed'? I have no problem with it.
If you're really that worried about 'https' in the URL bar, I'd be happy with a newly-defined 'httpe' or something, for encrypted but non-authenticated connections. Or a yellow warning bar that the page's origin cannot be verified.
Anything but the big pop-up implication that there's some huge security issue when someone goes from plaintext to unsigned SSL, requiring four or five clicks to get past.
Incidentally, I suspect that's some of what's causing the actual security issue of people trusting random web sites, in that people think plaintext browsing is somehow secure and people can't lie about their origin. Sure, it sounds crazy, but if people see a few giant security warnings, they could quite legitimately assume everywhere there's not a warning is secure.
Give me one situation where someone would "trivially snoop on a connection" without also being able to trivially run an SSL MITM attack, and trivially snoop on your wish-it-was-SSL connection.
There are at least two orders of magnitude difference needed to log web pages, especially if you're just grabbing the headers and POST variables, and needed to read, decrypt, reencypt, and send along web pages. Especially if you have to check which are signed by a known CA and not alter them.
There's a reason that Comcast wasn't altering torrent connections to disconnect them, and was instead sending TCP reset packages...it couldn't operate fast enough to actually edit the connections in situ. They're actually statistically sampling the connections because they can't handle the volume, and their system was operating from a copy of actual traffic, not 'in line'.
Remember, you'd have to intercept all communications. You couldn't encrypt half with one key and let the rest pass buy.
You're arguing just because something isn't technically impossible for an attacker to break means we shouldn't allow it. That's just crazy talk. We allow all sorts of 'moderate security' in the computer industry, a lot of actually aimed at passive spying, like logins for mail and http auth, which anyone could MiTM, and storefront software that doesn't store entire CC numbers, despite anyone being able to alter it to do that very quickly.
Saying 'Ha ha, anyone can MiTM, and asking for a security ability that can be defeated by it is stupid' is just security elitism. We're asking for 'wearing a badge' security, not 'fingerprint and r
If corporations are people, aren't stockholders guilty of slavery?
This wouldn't be possible in the switching system you advocate for.
Sure it would. The telnet protocol allows both ends to specify requirements, and results in a disconnect if the other end doesn't support it. (In fact, it appears to already support SSL, but I suspect that doesn't include certs.)
Granted, the client could lie, but that would be a protocol violation, and if we're considering those, nothing stops a client from spewing plaintext into a SSL connection either.
That said, the problem there is poorly designed protocols that allow one greeting unparsed message from the server and then the client instantly sends the login. This was yet another protocol stupidity, right up there without allowing switching to SSL via telnet negotiation. (Although if we'd used the latter, we wouldn't have worry about the former...telnet negotiation happens before any communications at all.)
SMTP, interestingly, doesn't have this problem, because SMTP wasn't designed with authentication in the first place. The server has to state the ability to login, via ESMTP options. IMAP, being a late designed protocol, doesn't have this problem either.
With both IMAP and SMTP, you connect, and get a message from the server, but that message has to state the various methods you are allowed to login.(Along with various other options.) The server can, in fact, state no login methods at all, and just present the 'I can switch to SSL' option. After the switch, it can present the login methods again.
Furthermore, a switching system entangles application protocols with the constantly mutating TLS, which would make maintenance of both more difficult.
I don't know what you mean by that. SSL negotiates itself quite well between different versions. A lot of SMTP traffic already magically switches itself to SSL. I myself have let my mail server switch to SSL (Well, TLS) on demand, and have had over 500 TLS connections the last two days. (Which is actually absurdly high for the amount of mail we get, so either spammers are using SSL or my grep failed.)
Although obviously, looking at it from that direction is stupid. Our mail server (postfix) also attempts to negotiate SSL connections for outgoing mail, and I've never seen mail bounce because it couldn't negotiate a connection.
Certificates change regularly for legitimate reasons. I see no reason to confuse users by alerting them when this happens.
Let me restate: Users should be alerted when an self-signed cert changes to another self-signed cert, or when a CA-signed cert changes to a self-signed cert.
Yes, what specific problem are you talking about? HTTP is for anything that doesn't require a secret (mod Digest auth); HTTPS is for everything else. What's the problem?
The problem is that negotiation happens before any other communications, so that clients cannot state what website they are actually connecting to, so the server cannot present the correct certificate for that web site. Which is why HTTPS sites need their own IP.
This actually would be a problem in other protocols, except no email client expect signed-by-the-email-domain in email SSL connections.
If corporations are people, aren't stockholders guilty of slavery?
Nonetheless, what I described—the client cannot talk to the server in the clear at all because the corresponding port is not listening—is not possible.
I mean that every protocol has to define a unique way to start TLS negotiation: LDAP sends a particular OID, SMTP uses STARTTLS, IMPP uses a <starttls...> tag, etc. Then the protocol has handle various failures gracefully.
With the separate port method, TLS is just a layer on top of the application protocol and the application protocol can focus on doing what is was designed to do. In addition, each application that adopts TLS as a native feature locks us in deeper to TLS, both in code added to implementations and in TLS-specific error handling. This makes it harder to swap TLS out for something better if/when that comes along.
Furthermore, SSL's being a mixed binary and ASN.1 protocol makes it very squirrelly when a line-based protocol such as IMAP or SMTP switches it on. At best, it's, shall we say, aesthetically displeasing.
That's a defect in the original design of SSL, which should give you an idea as to how well thought out it was (not very). This problem is addressed with the extended Client Hello, which is gradually being adopted in client software. Within a year or so, hopefully, virtually hosted SSL sites will be commonplace.
And I notice you completely ignored the 'And we don't have infinite IPs either' point when I demonstrated that the majority of web browsers do not support them.
You've got one, right?
How many domains do you need to support, exactly?
Online businesses obviously need authentication. A guy who can barely afford godaddy to run his joomla discussion board does not.
First, Joomla? Really?
Second, why does this disqualify him from needing authentication? All you're talking about is the economic impact (which I've demonstrated as pretty small). If we're assuming he actually can run SSL, which implies that he has his own virtual host, Godaddy charges something like $40/mo for that -- an additional cert (for a plan which doesn't actually include a free one) is going to be less than $2/mo.
That doesn't mean that I can't say 'I wish the web browser would encode this password using the encryption built in, instead of something written in this annoying language'.
Javascript is actally fairly powerful, and often misunderstood, but that's beside the point. It has a builtin method for exactly what you're asking, which is called HTTP auth. You just find it ugly.
It's a frickin giant dialog box, entirely breaking the paradigm of the web.
Paradigm? I don't think that word means what you think it means...
And it really doesn't, much -- you would just be implementing exactly the same thing in an HTML form, maybe with some javascript. It has the added advantage of being uniform -- every page that uses HTTP Auth will provide the same login form.
How the heck is that 'heavy handed'? I have no problem with it.
That's a great definition of "not heavy-handed" -- "something I have no problem with." That's serious Godwinbait.
I'd be happy with a newly-defined 'httpe' or something, for encrypted but non-authenticated connections.
Fine, go ahead. I don't think it's worth the effort it'd take to implement, but that's me.
Sure, it sounds crazy, but if people see a few giant security warnings, they could quite legitimately assume everywhere there's not a warning is secure.
That actually is pretty crazy. When driving past a prison, you see giant signs that say "Do not pick up hitchhikers." Does anyone assume that hitchhikers are 100% safe everywhere else?
There are at least two orders of magnitude difference needed to log web pages, especially if you're just grabbing the headers and POST variables, and needed to read, decrypt, reencypt, and send along web pages. Especially if you have to check which are signed by a known CA and not alter them.
Are you talking about performance?
In other words, it takes a few orders of magnitude more clock cycles on my laptop when I airpwn you. What does it matter to me, as long as I have enough?
Or are you assuming that I'd be trying to crack quite a lot more connections at once? What's the motive? Where is it that I have the opportunity to intercept enough traffic that the "orders of magnitude harder" even matters -- and for what purpose do I need that much data?
I'm not trying to say "you have nothing to hide" -- what I am saying is that I don't see a scenario where such an attack would make sense -- where it would have an economic incentive, even.
Especially if you have to check which are signed by a known CA and not alter them.
Which you don't, really.
Remember, you'd have to intercept all communications. You couldn't encrypt half with one key and let the rest pass buy.
First, I only need to accept all communications from the client I'm trying to 0wn. I don't need to intercept all communications from everyone.
Second, I only need to get lucky once -- I
Don't thank God, thank a doctor!
I mean that every protocol has to define a unique way to start TLS negotiation: LDAP sends a particular OID, SMTP uses STARTTLS, IMPP uses a tag, etc. Then the protocol has handle various failures gracefully.
Yeah, I agree. That's why I wish the telnet negotiation protocol itself had included SSL, enabling essentially all line-mode TCP/IP connections to switch to SSL on the fly.
Then we could have avoided all this silliness. All connections start plaintext, all of them switch to SSL without sending a single byte in-band. (Except if it needs to, like HTTP.)
That way it could be, like you say, a layer on top of the application. You'd probably get it free with sockets in libc. Stick a flag on the socket when you make it, and it only accepts SSL.
(Even better, of course, would have been, instead of inventing SSL, invent something that works like SSL entirely at the telnet negotiation level, where all connections are just 'plaintext SSL' connections, and to go encrypted, you just change the encryption used. But I don't know the history well enough to know if that would have been possible.)
Furthermore, SSL's being a mixed binary and ASN.1 protocol makes it very squirrelly when a line-based protocol such as IMAP or SMTP switches it on. At best, it's, shall we say, aesthetically displeasing.
No kidding. That's probably the worse method possible.
I know what you're saying about multiple ports being better than single 'upgradable' ports, and in a way they are, but having two ports means every piece of software in existence defaults to the unencrypted one.
So while you talk about hypothetical misconfigured software that someone failed to check 'Don't connect if cannot secure the connection', what's actually going on is that almost none of the population is using SSL ports at all. Their mail client defaulted to the standard ports, and it worked. If that port offers encryption, the mail client will upgrade, but it's not going to randomly look for the encrypted port.
I know this for a fact. I've been running a mail server for years, and it's moved between machines. Once, when I moved the mail server but not the webmail that was using the same domain name, I had to forward the IMAP and POP3 port to the new server, and I had already pointed my client there to test, so failed to notice I forgot to forward the SSL ports...for two weeks. No one even noticed. Out of forty or so people, not a single one was using an encrypted connection, not a single one complained their email stopped working. I only caught it when I fixed my client to use the old server name and couldn't connect.
SSL ports are only 'more secure' if there's a set of people who would go around setting up their client to use that port, but not setting up their client to require encrypted connections. I suspect this set of people does not, in fact, exist, and even if it does, it is vastly outnumbered by the people who just accept the defaults if everything works.
Within a year or so, hopefully, virtually hosted SSL sites will be commonplace.
Not until IE7 on XP supports it. For some reason, IE7 does on Vista, but not XP. Despite what MS likes to pretend, XP will be around a long time.
If corporations are people, aren't stockholders guilty of slavery?
How many domains do you need to support, exactly?
About a dozen on the server I've got could reasonable benefit from an encrypted, in that they have moderately sensitive information passing over them. Any CMS, for example, has at least an admin interface.
First, Joomla? Really?
And your ideal CMS is...?
If we're assuming he actually can run SSL, which implies that he has his own virtual host, Godaddy charges something like $40/mo for that -- an additional cert (for a plan which doesn't actually include a free one) is going to be less than $2/mo.
You are arguing in circles. The reason it cost that much is that Godaddy gives you your own IP and cert.
I suspect that if there was demand for it, which means it wouldn't pop warnings up all over the place, they'd give everyone SSL access, using a wildcard cert, via HTTPS, to their existing websites. For no cost. (Heck, it wouldn't cost them anything.)
In fact, thanks for that example, I think it just demonstrated my point for me better than I ever could.
I'm not trying to say "you have nothing to hide" -- what I am saying is that I don't see a scenario where such an attack would make sense -- where it would have an economic incentive, even.
And neither do I. Moreover, I'm failing to see why you think that failing to see why a MitM attack would be implemented somehow demonstrates your point.
Normal human beings are not subject to MitM attacks that SSL would protect them against. They really aren't.
Moreover, if they are, either they're going to fall for it regardless, or they're not going to fall for an unauthenticated connection that look sufficiently different from an authenticated one.
First, I only need to accept all communications from the client I'm trying to 0wn. I don't need to intercept all communications from everyone.
Second, I only need to get lucky once -- I only need to be faster than the DNS server for one response -- or, for that matter, the DHCP server. After that response, the client will connect directly to me.
If you are talking about targeted attacks, my point about encryption makes more sense. Because people use the same passwords all over the place. A single cleartext login and you've won.
Moreover, as I've repeatedly pointed out, if you're going to MitM someone with a targeted attack and editing web pages, the logical thing to do is to simply set up a real SSL server with a similar name to the bank, and replace the links in the banks cleartext webpages to that place.
Or just don't use any SSL at all.
Or, heck, just present an invalid cert, and insert a message on the cleartext webpage to click past it, and quite a lot of people would click past it.
I'm not sure why having the option to have unauthenticated encrypted connections helps any of those in the slightest.
I'm arguing that in a context where one might be expecting security, we shouldn't pretend something is more secure than it is. And I'm arguing that when there's a finite amount of development time to be spent improving browsers, I'd much rather it be spent on things like the HTML5 video tag, SVG, standards compliance, Javascript performance, etc, rather than on making mediocre security easier.
That's it. That's where you're at. You have no objection except the time it would take?
Well, okay then. I'm done.
If corporations are people, aren't stockholders guilty of slavery?
This is the sort of thing we could have with opportunistic encryption using IPsec. But for that we need universal PKI. With universal PKI, every system can have one or more public keys. Authentication can then be mutual between systems. The application protocols could be, as you suggest, almost completely oblivious to this; they will simply require a secure socket and an IPsec tunnel is created automatically.
If we ever get this, we may regret all the work that has been done to munge protocols with TLS awareness.
A big reason I advocate DNSSEC is because it has the capability to provide this universal PKI at no per-system cost to the domain owner. Once you have a signed domain, CAs are no longer needed because you have a superior chain of trust right there in the DNS.
I recognize that that's the status quo, but it's easy enough to fix. Admins just need to disable the cleartext ports and publish instructions for their users (not necessarily in that order ;^). Every one of my mail users uses IMAPS, because port 993 is the only protocol available. And even if they were to muck up the client config by changing the port to 993 without checking the SSL/TLS box, they wouldn't be able to get to the point of sending IMAP credentials in the clear, because the IMAP client won't be able to read a server hello.
Yes, a couple of years ago, this wasn't workable for the little guys. But with $20/year certs available now, it's kind of inexcusable to do anything else.
You are arguing in circles. The reason it cost that much is that Godaddy gives you your own IP and cert.
Fine. You write the scenario.
I'm on Slicehost -- that's $20/mo. IP is included. Cert is, as I've said repeatedly, $15/year. (Except when I thought it was $10/year -- sorry about that.) Insignificant next to hosting costs.
I suspect that if there was demand for it, which means it wouldn't pop warnings up all over the place, they'd give everyone SSL access, using a wildcard cert, via HTTPS, to their existing websites. For no cost.
Well, there are two options there:
Either you put everyone on a subdomain, or a subpath of the same domain -- think Freewebs -- and this might cause XSS issues...
Or you actually start handing out certs for free, without doing any background checks. That wouldn't cause giant warnings -- until the people Godaddy is reselling from invalidated their cert, and/or browsers started removing that root cert, as it's obviously not trustworthy for verifying identity.
(And you're assuming they wouldn't want to use that demand to basically print money.)
Or, you do the background checks -- but this costs money. How do you earn it back? One way is to charge people for the service of identifying them, and... hey! That's how SSL works right now.
Passports -- real, physical ones, that you use to go to other countries -- aren't free, either.
Moreover, I'm failing to see why you think that failing to see why a MitM attack would be implemented somehow demonstrates your point.
Actually, I was talking about your passive attacks.
Or, heck, just present an invalid cert, and insert a message on the cleartext webpage to click past it, and quite a lot of people would click past it.
Which is actually an argument for my point -- make the warning bigger and more obnoxious, so that people actually realize that there's a real security implication, not just another thing to click through without reading.
You have no objection except the time it would take?
Given that you're talking about implementing a whole new URI scheme, and pushing it into major browsers, I think that's a lot of time. I'm not even counting time to educate users.
Given that one of your complaints about my suggestion to "just get a real cert" is that SSL with virtualhosts isn't widely supported enough, I also don't really see the point. We've now, again, reduced the cost of real SSL to $15/year, or $1.25/month -- and that would have wider support than "httpe".
However, making it indistinguishable from plaintext is a bad idea. Making it indistinguishable from verified SSL -- or allowing the possibility for someone to confuse it with SSL -- is a much worse idea. That is what I was arguing against.
And I still don't like it. I think the benefit from it is so small (really, certs are cheap), and the implications are yet another thing which people should learn in order to be secure on the Internet, that it would be better not to have it.
And I think that, moreover, there would be a brand new meme of misinformation that your httpe is "secure enough" for whatever purpose, among people who otherwise would buy a cert, and would be better off for it. (Take rubyforge.org as a shining example of someone who already does this with self-signed certs -- though maybe I should ask and find out why they do it that way.)
But at this point, I think I'm done. After all, my browser already supports things like a fish:// URL scheme, as well as zip:/ and other fun things. People invent new URL schemes all the time -- there's steam:// for Valve products on Windows, "magnet links" for Azureus and friends...
So ultimately, my objections don't matter. Either you'll get it standardized, in which case, it'll hopefully be much more thoroughly debated (and be much improved as a result) -- or you won't, in which case, it'll be a nonstandard extension, something between you and your users, and my opinion won't really matter (kind of like Flash -- fucking Flash...)
Don't thank God, thank a doctor!
True. When you are providing services to the general public you need a trusted 3rd party to verify your identity.
> the big problem is that Firefox hasn't imported CACert root certificate in it's trusted
> database yet.
Of course CACert hasn't asked to be imported and hasn't provided the information that would be needed to import them...
if the warning sign is too prohibitive for the non geek people and if the adding exception process is too much effort (it is), it means that practically ff3 forces usage of paid certs. and if you go for a paid cert, you dont go for less recognized certs like a moron. there are 4 mainstream certs in market, comodo, rapidssl, verisign and geotrust. you cant be sure with the comodo and rapidssl recognition rates, but geotrust and verisign are the most recognized certs. and geotrust belongs to verisign.
so in theory what you say holds true. whereas in practice, it doesnt.
Read radical news here
you're basically praying that no one who is capable of sniffing your packets realizes that they could probably alter them, too.
You do understand that to pull off a "Man in the middle" attack, you actually have to be in the middle, right? (From a network architecture perspective). A peer node can't modify your packets, it's not a matter of just using different software. If you don't recognize that peer nodes are the largest threat (compared to ISP infrastructure) then you're not living in the real world.
The "False sense of security" argument is BS. *I* get to determine what level of security I need for my purposes and budget. SSL, self cert or otherwise, is just one tool in the bag. A browser cannot and should not make that decision for me.
the passwords I use remotely, I mostly have my browser memorize, or they're keys instead of passwords -- so they would have to steal my machine in order to do it.
You're storing your login to SSL sites in your browser? Are you kidding me? No, they don't have to steal your machine, they can just sit down at it when you walk away and forget to lock it. Or they can use administrator level access or somebody else's compromised credentials to go steal your browser's profile or just copy the cookie. Or get it from a backup. Or use a remote exploit. Or turn it off and clone your drive when you're not there. Etc. etc. etc.
No. I do, however, use Dvorak, and type extremely fast.
Talk about security by obscurity. You're rant afterwords is akin to what I'm saying about SSL - you know your environment, you know the likely threats and you are implementing security measures (or not implementing them) based on those perceived threats. That's exactly what I'm saying, thank you for making my point and agreeing. I think we're done here.
This is the sort of thing we could have with opportunistic encryption using IPsec.
The problem with IPsec is, frankly, it is never going to actually happen.
And the problem with SSL is that there's no protocol-level independent generic 'negotiation'. It really really should have been designed to start plaintext and switch over, which would have allowed magically building it into every TCP server. TLS is designed to switch over, but not in a protocol independent way, so that's even more annoying.
I recognize that that's the status quo, but it's easy enough to fix. Admins just need to disable the cleartext ports and publish instructions for their users (not necessarily in that order ;^). Every one of my mail users uses IMAPS, because port 993 is the only protocol available. And even if they were to muck up the client config by changing the port to 993 without checking the SSL/TLS box, they wouldn't be able to get to the point of sending IMAP credentials in the clear, because the IMAP client won't be able to read a server hello.
Ha, I wish I had as much authority over my server as you. There's no way I could justify breaking everyone's mail connection...again.
I have actually done something like this once, I stop accepting mail submissions on port 25 and made everyone use the smtp submission port. (And the stupid smtps submission port) I was able to justify that because about every month someone would call and tell me 'the mail server was broken', when in fact they were on a new connection, or their ISP had just started, to block port 25. And I eventually said to hell with it and made everyone switch off 25 at once, as I was able to convince my company that, eventually, the amount of problems using port 25 was causing outweighed the amount of problems switching it off all at once would cause.
I doubt I can use the same logic for unencrypted connections. If it's not broken don't fix it is the motto at most companies, and definitely don't fix it in a way that breaks current setup for people.
Meanwhile, I run SSL ports, if anyone uses them, and I have TLS switching on my main ports. Which means if anyone's bothered to click any security setting, or the client does TLS by default, it's encrypted.
Grepping the logs, almost no one does.
If corporations are people, aren't stockholders guilty of slavery?
Either you put everyone on a subdomain, or a subpath of the same domain -- think Freewebs -- and this might cause XSS issues...
Or you actually start handing out certs for free, without doing any background checks. That wouldn't cause giant warnings -- until the people Godaddy is reselling from invalidated their cert, and/or browsers started removing that root cert, as it's obviously not trustworthy for verifying identity.
Godaddy doesn't have to hand out the certs they use. They simply have to set up a listening server on port 443 with the same virtual domain setup they have, and put a * cert on that.
However, making it indistinguishable from plaintext is a bad idea.
I wish you would EXPLAIN WHY instead of just saying it is. Just asserting things does not make them true.
An encrypted connection without authentication should be trusted, by the end user, as much as plaintext. I'll accept that. (1)
So how is making indistinguishable from plaintext a bad thing?
1) Although I will still argue that the system as a whole is much more secure from outside tampering, in the same way that sealed envelopes are more secure than postcards, despite the fact that almost anyone can file a change of address form at a post office or steal from their mailbox and intercept someone's mail, open the envelopes, and replace them in the end mailbox after tampering. Requiring people stealing your mail to go to all that trouble, instead of letting everyone read and write on your mail and happily send it on its way with no trouble at all.
If corporations are people, aren't stockholders guilty of slavery?
But the reason IPsec has not become commonplace is the lack of universal PKI.
In any case, IPsec is not necessary to replace TLS. A modified TLS-like encryption layer can use DNSSEC (or whatever ubiquitous PKI) to acquire public keys securely; they don't have to be signed by a CA as long as there is some other trust chain available. The key is to make it cost nothing to set up this trust chain for each host. Since DNSSEC is needed anyway to solve DNS cache poisoning, we might as well use it to provide universal PKI. It would be silly to pay a CA to try to prove, via cleartext email, that you control a domain, so they can sign your public key, when you could instead simply add it to the DNS.
All you need to do is adopt a policy that all credentials have to be encrypted in transit, and then you have the leverage you need. Any company that considers its proprietary information to be private should have a hard time arguing with that. And it's easy enough to demonstrate to management bozos how trivial it is to sniff passwords off the wire.
You don't have to break it, initially. You can just auto-nag all the users that use cleartext ports until they stop, then disable the cleartext ports.
Any CA that signs a cert for * should have its CA cert revoked.
Frankly, anyone that uses a wildcard cert should have his ears boxed a few times. Wildcard certs are a moronic devolution that is driven by the economic model of the broken X.509 PKI we're using. We can do better.
If, by "peer node" you mean a node in the same broadcast domain, you are 100% wrong. A "peer node" can very easily put itself in the middle, via arp spoofing, DNS spoofing, etc.
"Peer nodes" have the most direct access to your traffic. That doesn't make them the largest threat for most people, since for most people there are relatively few attackers on "peer nodes". DNS cache poisoning can be effected by the much larger population of remote attackers.
"Peer nodes" have the most direct access to your traffic.
That is exactly why it's the most dangerous - they see ALL unencrypted data coming out of your computer, hence the desire to encrypt as much as possible coming out of your computer with SSL (HTTP/IMAP/POP/whatever). Anything else has to be a more targeted attack. Peer nodes attack the low hanging fruit. It's like locking your car door in the mall - sure there are other ways to break into the car, but it's just easier to move on to a better/easier target. That's my car analogy for the day.
doesn't make them the largest threat for most people, since for most people
You're confusing largest threat with largest exposure, the two are not directly correlated, I'm making a subjective observation due to the point immediately above and noted in prior responses - the reason I use self-cert SSL is to get out of perceived hostile local environments.
I agree that a CA signed cert is "better" than self-signed, though still not perfect and not uncompromisable, just "better". But the point is if somebody makes a financial choice to only use a self-cert, they are still better off than not using a self-cert. Again, you yourself even made a similar point - why introduce more vulnerabilities? There are two problems that SSL can possible help with (read original article), and self-certs help with one of those problems. I can't, for the life of me, comprehend why anybody would want to eliminate that option.
And I assure you that you are indeed wrong. You only need to win these races once and you can remain interposed as long as you like. In fact, you don't need to win a race at all with arp spoofing. A targeted gratuitous arp will generally do the trick, and the host you're spoofing won't even know it happened because it never sees it. Hosts only arp when arp entries expire from cache, which is easy to prevent—just keep sending traffic to the respective hosts.
As for DNS spoofing, it's trivial to beat the DNS server at answering a resolution request.
Sure, "better", in the same sense that "useful" is "better" than "useless".
I wish you would EXPLAIN WHY instead of just saying it is.
It falls under "hiding things from the user", which I generally consider to be bad -- and could have unpredictable results.
A contrived example: I've installed a new BB system -- or blogging engine -- whatever. I've configured everything properly, or so I think, and I'm wondering why most pages work, but certain pages just seem to hang forever.
Or, alternatively, I'm trying to access someone else's site, through a heavily restrictive censoring firewall. Again, certain pages work as intended, and certain pages hang forever, until the connection times out.
With at least some distinction in the URL scheme, I might think to myself, "Aha! These are SSL requests of some kind! Port 443 must be blocked somewhere!"
Requiring people stealing your mail to go to all that trouble, instead of letting everyone read and write on your mail and happily send it on its way with no trouble at all.
Given that all of this must be done manually -- calling the post office, intercepting the mail, physically opening the envelope, finding an identical one, and replacing it -- or opening it carefully, so as to be able to re-seal it with no evidence of tampering -- all of this requires a significant investment of time and effort, and a small investment of money.
All you're doing is requiring people to download a somewhat more sophisticated version of airpwn.
Kind of like how using rot13 is pretty pointless, for any data you actually care about. Security through obscurity, plain and simple.
Don't thank God, thank a doctor!
Sure, "better", in the same sense that "useful" is "better" than "useless".
The fact is if all network traffic were encrypted without authentication (a method on which many protocols operate, as you even provided examples of), there would be a net gain in security. I don't know what you think is different about SSL. You have yet to address my primary points in any of these responses, clearly you simply don't have an answer. Good day.
Beating a DNS server's response on a local network is only trivial because it's trivial. What do you imagine makes it the least bit difficult? Even if you didn't have better latency than the real nameserver, the real nameserver has to ask someone. You don't--your lie is ready to transmit as soon as you see the request.
You clearly have never done any this. I haven't even mentioned, oh, say, using a rogue DHCP server...
No, there would be net gains in CPU utilization and difficulty of debugging network problems, both of which would lower security. Encryption without authentication is useless. You walk into a crowded, pitch black room and say "John, come over here; I want to tell you a secret." Someone comes over, and you whisper your secret to him or her. Well done!
I don't know what examples of protocols that encrypt without authentication you think I provided examples of.
Perhaps you could indicate which points you consider primary, so that I can correct any additional errors you may have made there as well.
Let's try this a different way. Let's try to isolate where our disagreement lies. Specify to each of the following what you would agree, or not agree to:
Let's start there, just list out each one of those and if you agree or disagree with the statement.
You appear to be confusing me with someone else. I haven't discussed ssh with you. In any case, trusting ssh host keys without verifying them is something that you shouldn't do, and the ssh client suitably warns you when you are about to do so, just as Firefox warns you when you are about to use a self-signed cert you haven't previously asserted as trustworthy.
In the future, hopefully, ssh host key validation will be automated using DNSSEC.
No, that's not an example, unless you failed to validate the public key of the recipient. You are confusing authentication of the peer with authentication to the peer. And even if you do sign the email, the peer still has to validate your public key before you've authenticated to him. This sort of confusion is a good example of why general users need to be sternly warned about self-signed certs—it's easy to get mixed up when you're trying to do crypto.
I agree in principle with all of your assertions. What's missing is how those assertions can lead you to conclude that Firefox should be more tolerant of self-signed certs than it is.
You appear to be confusing me with someone else.
You are correct, my mistake, there were two different people to who I replied in the same thread.
No, that's not an example.
Sorry my example was poorly worded, I meant the user in this case being the recipient, not the sender. The recipient received an encrypted mail (using his public key) that was unsigned. Must he disregard the content under all circumstances? Or could it possibly be that the encryption was meant to keep prying eyes from reading the content instead of serving another purpose? That was my point.
I agree in principle with all of your assertions.
If you agree with all of those assertions how can you call encryption without authentication useless? They are two different problems, and solving one problem is better than solving none. If you take a hard stance on this point because of another potential attack vector, then how is any solution ever good enough when there will always be another potential vulnerability? One of my points is that there is a line - there is always something that can be compromised that is out of your control, using a CA isn't a panacea.
Going back to your previous reply:
You walk into a crowded, pitch black room and say "John, come over here; I want to tell you a secret."
Wouldn't it be more akin to calling John via cell phone (self cert SSL) instead of yelling out what you want to say for all to hear (plain text)? Sure, somebody (at the phone company) could re-route the call and maybe they could also mimick John's voice, and maybe they later call John and spoof your caller ID and mimick your voice and relay to him what you said, but if I'm not concerned with those things I'm still better off quietly calling John in the pitch black room instead of yelling it out for all to hear. I have prevented at least some people in the room from hearing what I have to say.
What's missing is how those assertions can lead you to conclude that Firefox should be more tolerant of self-signed certs than it is.
I'm glad we've cycled back to the original article. Let's talk about the recent versions of Firefox (Fx). Fx2 did in fact warn you of a self signed cert, to which a user could simply click OK. Fx3 now requires 3-4 clicks to do the same thing. That's just being in the way for no good reason - a warning message and maybe a colored URL bar would be fine. There was also a time during the Fx3 beta when it was not possible to bypass the dialog for self-signed certs AT ALL, thus rendering access to a self-signed cert site impossible. Fortunately the mozilla devs changed their minds on that one before the stable release. There is still, however, other cert errors that are not bypassable in Fx3 that were in Fx2. Here is one of them: https://bugzilla.mozilla.org/show_bug.cgi?id=312732. This one does have a "workaround" that is fairly difficult and requires some guessing. So Firefox is unnecessarily getting in the way for much SSL usage, going well past a simple warning dialog.
Any company that considers its proprietary information to be private should have a hard time arguing with that. And it's easy enough to demonstrate to management bozos how trivial it is to sniff passwords off the wire.
Ah, but this isn't a single company. We're webhosts for a dozen or so businesses, and a few cheap local non-profits, in addition to running our own websites and storefronts.
Company computers are set up with encryption. (At least since I discovered that no one else was using it.) It's the other guys who aren't.
But your idea isn't a bad one. I need to figure out if I can determine from the logs who's using TLS over standard ports (I know I can see who's using SSL ports.) and start talking about a 'security upgrade' that will, sadly, require certain people to fix their email clients.
If corporations are people, aren't stockholders guilty of slavery?
I suspected as much. It happens...
I'm still not sure the example is what you intended. If someone sends me an unsigned, encrypted email, and I can read it, then the sender is using the correct public key, and no one else but me can read the message. The opportunity for subterfuge in this kind of scenario is that an attacker may give the sender a forged public key for my email address, and the person who uses that public key will generate an email which I can't read, but which the attacker can.
In the SSL scenario, the recipient is the SSL server, and whatever entity is connected to the server will use the public key the server sends in the Server Hello. A man in the middle could substitute a different public key in that step, but the conversation would stop when the server couldn't decrypt the client's message. As far as signing, unless you're using client certificates, the SSL process doesn't authenticate the sender; if the server requires authentication this is typically accomplished using a password at the application layer. If a bank didn't require you to authenticate somehow, and let someone transfer money out of your account, that would be a problem, just as it would be if someone sent me unsigned instructions, and I followed them without requiring some other form of authentication in the content of the message.
The confusion arises because the term "encryption" by itself is too unspecific, and is being used as shorthand for what's really going on. "Encryption" between two parties is fine, but that presumes that those parties have already established a shared key. That is, the point of encryption is privacy, and to have privacy, some method must be used to establish a key that only the parties in question possess. Publishing an encrypted document along with its private key doesn't accomplish anything useful, even though the document be properly encrypted.
The problem here is with the key establishment phase, because there is no evidence that you are establishing a shared key with the party that you want to talk to, rather than a malicious third party. Yes, "encryption" and "authentication" are two different things, but you can't do what "encryption" is short for in this context without having to authenticate first.
Similarly, in the pitch black room, you have "privacy" when you whisper your secret to the person who walks up to you—only you and that person know the secret. That privacy is useless, though, because you don't know whom you were being private with.
The difference is that doing all the things you describe is difficult, and there aren't publicly available tools for it. Being a man-in-the-middle in an SSL session established with an untrusted cert is easy. There are readily available tools for hijacking SSL sessions, and these tools keep getting better. Positioning oneself as a man in the middle is now easier than eve
Kaminsky's presentation from Black Hat makes it abundantly clear that still we have a long way to go in terms of DNS remediation. Until then, man-in-the-middle attacks continue to be quite easy to accomplish.
I appreciate the response. I think I'll still connect to my self-cert IMAP mail server via SSL rather than plain text. It also provides the added benefit of bypassing most content filtering firewalls :)
Clearly we have different ideas as to what is easy and what is difficult in pulling off an attack, and what is and isn't worth bothering to protect yourself against. A passive listener (Eve) seems to be much more common and very easy to protect against than an actual attacker (Mallory). If you're worried about that more aggressive attacker it seems to me that CA provided SSL isn't enough, you need to worry more about the endpoints as well. I totally get what you're saying about the availability of tools, but they're far from automated. Getting fragrouter/ettercap/dnsspoof/webmitm/wireshark/ssldump to attack/trap/decrypt/re-encrypt/pass all other traffic/store/filter data all at the same time, in real time, in two directions is not trivial. Maybe metasploit put something together I haven't seen. But setting up any of a number of different packet sniffers with a simple filter for "username" that will work for pop/imap/telnet/ftp/http/etc traffic is much easier; I could walk my mom through it over the phone.
The caller ID spoofing bit of the phone attack I described isn't that difficult at all actually, there are many websites that will do it for you easily - they have made the news from people being scammed and whatnot.
It all just comes down to your perception of the threat based on your own knowledge. That's why choices are good.
But presumably you've already added that certificate to your local store so it's trusted. And if you're providing that service for a number of users, why don't you buy a $15 cert from a cheap CA?
Again, Eve has to be on the network path, which few attackers are. Mallory can be anywhere if he can poison your DNS. Getting the DSniff stuff working is not difficult at all, and you don't even need that—a couple of stunnels connected by a logging script is sufficient. It's 20 minutes' work to set up. You don't even need to log both directions; client-to-server is where the credentials and credit card numbers are.
Understanding the threat requires considering more than the superficial difference in difficulty level between plain sniffing and setting up a man-in-the-middle attack. The potential reward to the attacker and the amount of effort required are important factors. With sniffing, the reward is small because you only have visibility on a small number of machines, and the effort required is large because you have to compromise a system on the network path for each victim, and monitor all traffic waiting for a few credentials to pass by. With a DNS-based man-in-the-middle attack, you just have to set up a proxy and poison a cache at one of the large ISPs and you can have literally hundreds of thousands of victims. The DNS-based attack can be targeted at the institutions you want credentials for, and you don't have to look at unrelated packets; the only traffic you see is directly related to the information you're looking for.
To me, it's obvious that the man-in-the-middle attack is a far, far larger threat, and I suspect the decision at Mozilla was informed at least in part by some advance knowledge of the Kaminsky DNS attack.
Spoofing Caller ID was just one of the challenges in the attack you described. The attacker also has to be able to intercept calls and mimic at least two voices. If you want to talk about a scenario where the only authenticator is caller ID, then yes, I would agree that's somewhat like using a self-signed cert, though still perhaps more difficult to pull off than an SSL man-in-the-middle attack.