Slashdot Mirror
When Is a Self-Signed SSL Certificate Acceptable?
UltraLoser writes "When is it acceptable to encourage users to accept a self-signed SSL cert? Recently the staff of a certain Web site turned on optional SSL with a self-signed and domain-mismatched certificate for its users and encourages them to add an exception for this certificate. Their defense is that it is just as secure as one signed by a commercial CA; and because their site exists for the distribution of copyrighted material the staff do not want to have their personal information in the hands of a CA. In their situation is it acceptable to encourage users to trust this certificate or is this giving users a false sense of security?"
Are you talking about the SSL certificate for "the Pirate Bay"? In that case, yes, it is fully understandable why they can't afford to apply for a proper certificate. And I guess the audience doesn't mind either.
In all other cases it's a big NO NO
http://revj.sourceforge.net
Can you cite any examples of a case where a certificate has been subverted in this way?
And while you are on your soapbox, what is the alternative? By what other method do you suggest that I prove to my satisfaction that when I go to www.mybank.com.au that I am actually at mybank's website, and that a dns record somewhere hasn't been subverted and I am instead entering my login details to a phishing site made up to look exactly like my bank?
I'm pretty sure you are talking out of your arse. Unless you can cite some examples of a big name company (eg a major bank) having had their certificate subverted in this way, and not having said certificate revoked almost immediately, i'll stick with what works thanks.
I totally agree - The internet would be FAR more secure if there was a way of using self-signed certificates without browser warnings.
But the certificate vendors have a licence to print money and abuse it horrifically.
For example, a certificate for a domain www.example.com costs a fraction of what a certificate for a wildcard *.example.com would cost. What extra work do they have to do for that extra money?
ALL sites would be more secure with a self-signed certificate than plain HTTP. But self-signed certificates scare the crap out of visitors with their alarmist warnings. If anything, the warnings should be shown on plain HTTP sites saying "Watch out! This isn't encrypted".
So. I say get rid of the self-signed warnings from all browsers, they do far more harm than good. Instead, make it clear on the browser with colouring, icons, whatever, whether the site has a verified certificate from a CA, or it does not (in the case of self-certs or HTTP).
Jolyon
Please read my Canon EOS tech blog at http://www.everyothershot.com
I'm a software developer and will often create my own certificates for testing purposes, and in my test lab people will trust them, however out in the wild there is no excuse for not getting a proper certificate signed by a proper authority.
Not only is this coming across as the company trying to do things on the cheap it has the possiblity of unraveling the trust of SSL for places you actually care about. If this becomes wide spread just think of the phishers create a copy of A Bank's site make their own SSL and put a note on the login screen "Dont worry you have to do some work to trust this certificate everything is alright honest guv."
Personally I normally trust self signed SSL certificates for sites I visit if they have them as i know the risks, but to potentially undermine for general users is just mad.
In my opinion SSL mixed two requirements, identification of site owner and secure communication.
This meant that many sites applied for SSL certificates just for secure communication. Some certificate authorities virtually issued certificates on request.
To get round they introduced extended validation certificates, which means we really, really validate this site.
They should have allowed secure communication without certificates, and had properly authorised certificates to start with. Since they didn't we have the situation where people have to self-sign
IMO, self signed certificates can be more secure. And for the site in question there's a risk of governments strongarming the certificate authorities to provide signed certificates so the government can launch MITM attacks.
I have a https website on my home machine that occasionally I connect to from work.
Now I get a popup about how the certificate issuer isn't recognised etc.
If someone at work (who controls the browser, the proxy, the network etc) decided to sniff all SSL traffic - which they could do with a MITM attack because they control at least one of the allowed root certs in the browser - my popup would disappear (unless they were very careful)
Likewise, my mail servers all use self signed certificates. Again, someone trying to attack me by getting verisign (or whoever) to sign a certificate, will not work.
Self signed certificates don't prevent attacks but they do mean that the attack cannot easily be automated.
(Actually I have a single self signed root cert that I then use to sign all my other certs rather than each cert being self signed)
It's swings and roundabouts. Verisign et al have built a whole industry out of convincing people to trust them more than the person's own bank.
I'm surprised we don't already see spam attempting to get people to install new root certs. (Or maybe we do - almost all the spam I get gets stopped by greylisting or caught by spamassassin)
Tim.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
Accepting a certificate ultimately comes down to trust. For example, most people trust Verisign. Therefore, if a certificate is signed by them, most people will think: "Here is a legitimate site with identifiable credentials accepted by Verisign."
A self-signed certificate encrypts your data just as well as any other. However, you need to trust the website you are at (and hence the signing authority). The reason people trust sites like Verisign, is that it is often difficult to know how legitimate/secure/etc a particular website is. Also, a website could be faked.
I'd trust a self-signed certificate from my bank. But I wouldn't necessary trust that the site I am at is actually my banking website (instead of a cleverly copied phishing scam).
Also, even if I trust a site, I wouldn't necessarily trust the people they trust. What I mean is that if a certificate is signed by an external CA, or with a mismatched domain, I would have to know and trust that CA or other domain before I would accept that certificate.
Considering that most people just click "OK" when something pops on their screen, I would say that Verisign and the like are useful for now. But I have nothing against self-signed certificates in principle.
Unity in Diversity
Not nearly as much damage as would have been done if everyone used self-signed certs. Look up 'man in the middle' attack.
"When is it acceptable to encourage users to accept a self-signed SSL cert?"
The answer is: Never.
What is the point of being sure that no one can intercept your communication all the way from your browser to the server if you don't know who you are talking to in the first place?
If someone knocked to your door and asked for your money would you give it to him because he has a bulletproof truck so the money will be safe all the way to whatever it is going to? Or would you trust the guy in the truck because he showed you a self-signed document saying: "I am authorised to do what I'm doing. Signed: me." Of course not!
But you'd be happy if you'd arranged with your bank for a truck to come and pick up the money, and when the truck arrived and you asked to see his documentation he said "Here it is, guaranteed by Fred Bloggs over there." And you have no relationship with Fred Bloggs (although you guess your bank does because the driver says so!) and no comeback against Fred Bloggs if he screws up even if he does have a relationship with your bank.
Quite frankly what I'd want is my bank having its own root cert that was self signed. I can confirm with my bank that I've got the right cert. And then when the driver turns up he can say "Here it is, guaranteed by your bank". And if the bank has screwed up and let some third party get hold of their root cert private key then I've got a relationship with the bank and I can sue them.
And when I communicate with my bank I should be able to give them my root cert and then they can check I'm who I say I am (they can use other methods as well if they don't think that is secure enough)
IIRC the hmrc website (UK TAX) allows you to use client side certificates to communicate with them but doesn't allow self signed ones. But why not? Is hmrc more confident that verisign can tell who I am than hmrc itself is? As a result I don't use a client side certificate.
Tim.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
Certificate key signatures can prevent MITM attacks. Provided someone doesn't MITM the signature exchange...
CAs are good, but, as I point out in another comment, most of us treat them magically. We don't do anything to verify our trusted cert lists. Can you tell me right now *with certainty* where your trusted CA list came from and that it hans't been modified by someone hostile or by hostile code?
If you can't tell me that for sure, then you are *less* secure than someone using unsigned certs who has personally verified key signatures face-to-face.
The answer is: Never.
Actually, the answer is: Always.
if you don't know who you are talking to in the first place?
For most purposes it's sufficient to know I'm talking to the same guy I was last time.
Or would you trust the guy in the truck because he showed you a self-signed document
Instead I'm supposed to trust the guy in the truck because he shows me a document signed by the guy in the truck next to him?
The economic interest of a CA is diametrically opposed to their purpose. They maximize their profit margins by _not_ doing what they should be doing; hence I have no more reason for trusting Verisign (the guy in the truck next to him) than the guy himself.
In fact, I'd be better off establishing my trust once with the guy in the truck, then accepting that trust in the future; trusting the CA merely means I've opened myself up to being blindly tricked coercion of the CA. If the certificate of the person I've established trust with changes I know somethings up. If I'm subjected to a MITM attack signed by a trusted CA I wont even notice.
False sense of security
Funny, I'd say that the false sense of security is exactly what you get from CA signed certificates.
For simple websites, why not, but for complex service-oriented systems, absolutely not as working around eronious certificates requires you deliberately code exceptions for.
Bad licences ultimately give you a bad testing environment, and seeing how SSL certs aren't expensive, I would say get SSL certs where possible.
throw new NoSignatureException();
This is timely, as I'm looking at implementing SSL for a web system at the moment, and I'm seriously pondering using self-signed certificates. Paying for a certificate from an authority is, quite frankly, a rip-off. The companies don't need to do anything for that money, and the notion that they provide some service where you can trust the site for the issued certificate is laughable. The only reason for doing so is so that peoples' browsers don't complain when they come across a certificate they don't recognise.
The cynic in me believes that Firefox and IE are giving you all sorts of 'helpful' warnings these days, not to protect a user's security, but to push website developers into buying certificates.
Using certificates is about one thing - encrypted communication between browser A and server B. That's it. Certificates have never given you any guarantee as to the integrity of the site that you're visiting, and it gives no guarantee whatsoever of who you are talking to, as some people are stupidly claiming around here. To give a guarantee like that, further technology is needed.
As a rule of thumb, if you have a finite number of users logging into a system then a self-signed certificate is OK, and even preferable. If you have some kind of site where the users you can have can be anyone (shopping site for example), then it's preferable to buy a certificate - if nothing else, to keep people from getting infernal warnings popping up in their browser.
The problem with SSL, and the tension between ID verification and simple encryption, is not so much a technical issue as it is a "people, on average, cannot be trusted for anything more complex than tying shoelaces". With depressing regularity, studies show people with no clear idea of what the "lock icon" means, no understanding of the fact that a picture of a lock displayed on a website and a lock icon in a browser are two vastly different things, and no real idea of how certificates work, or what a Certificate Authority actually is.
To compensate, browsers have ratcheted up the warnings given about self-signed certs to extreme levels, making them essentially useless for any site or service catering to the general public. This, then, creates a demand for cheap certs, which leads to shoddy verification, which defeats the purpose, which leads to E.V. certs, which are what certs are supposed to have been all along, only more expensive and with a snazzy green bar that nobody understands. Fan-Fricken-tastic.
What we really need is a clear distinction between "identity" certs and "stability" certs. Identity certs would essentially cover cases where trust in a given entity is a function of official verification; e.g. when I walk into a bank, my level of trust is based on the legal status of the bank, is it an FDIC member, where is it incorporated, are its financial data properly disclosed, etc. In this case, an assigned SSL cert is just one more official aspect of the entity.
The stability cert is different. It maps roughly onto the class of interactions that are based on reputation and patterns of behavior. You don't trust your best friend because you've checked his official ID, and you know that he is who he says he is, you trust him because you have been able to observe his behavior and interactions over a period of time. For this case, you don't need an SSL cert that is tied to a real world name, you need one that shows continuity over time. For example, knowing my real name would be of essentially no use in deciding whether or not to trust something I say in a post. Knowing that I am the same fuzzyfuzzyfungus who has posted in the past allows you to read my old posts and decide if I am reliable or not.
The solution to this need is not CAs in the classic sense, that verify identity then hand out a cert; but public repositories wherein people can deposit self-signed certs at a certain point in time and have that event on file, among a number of repositories, for anybody who asks. Then, if you go to my website, you can look at my cert and, rather then getting something useless like "certificate for foo-barr.org was issued to Mr. foo barr by Verisign", you can see "foo-barr.org has operated under the same entity's certificate for x years." From this, you could then judge the entity based on their last x years of activity.
The trouble with this notion is that it would require a subtler set of distinctions than the current setup, which people are, on the whole, already uselessly befuddled by. Oh well.
But there you're solving a completely different problem!
The SSL certificate scheme is there to assure your browser (you) that the bank is who they say they are.
The electronic pad and/or card are there to assure the bank that you are who you say you are.
Completely different problems. Without the first being solved (usually via SSL) then you have no idea who you're giving your username, password and one-time number to.
IMHO this is a MAJOR problem in security. Most people don't understand that there are multiple different issues of trust, secrecy and integrity to be solved in any given situation.
Which takes more work: doing what you said, or being annoyed by having to click through a few dialogs a few times?
Hell, if this was really an inconvenience, I'd switch the company's browsers NOT to use Firefox, since it's actively slowing down my employee's work.
This is really a bug in Firefox 3. Having to click 8 times to use a self-signed cert. is ridiculous.
No.
The function of the KEY is encryption. The function of the certificate is authentication.
Big difference.
"Rune Kristian Viken" - http://www.nwo.no - arca
False dichotomy. You present two options: ultra paranoid verify everything; and verify nothing. There is in fact a third option: trust MS to publish a list of well established and trusted vendors, and trust those vendors to vouch for a sites authority. That is a third option. And for most people it's the preferable option. If not, it would not be so.
no no no, really you don't understand. Since the login page is not encrypted, it may have been changed during transfer to your browser. You'll be sending your user credentials to the evil MITM.
See? since you can't trust the login page it doesn't matter that your username & password are sent using SSL, since you'd be sending them encrypted to the evil MITM.
WHich browser is it that falls back to HTTP when an HTTPS connection is terminated due to the SSL cert being rejected?
http://en.wikipedia.org/wiki/Certificate_signing_request/
And yet they still have an unencrypted login on their home page. Submitting to an encrypted URL from an unencrypted URL is practically a phish in itself. Most banks do this, and I cringe every time I see it. It begs for a phish attacks, does a disservice to customers, and promotes bad computing habits. But hey, it doesn't really cost the bank anything if your username and password gets whacked.
Not really. A phishing site could get its own SSL cert for whatever domain it's using. For example, a bad guy could get a cert for paypa1.com and https://paypa1.com/ would work just fine with a proper secure connection.
The idea is that Verisign or whatever CA granted the certificate should have checked them out, and only give them a cert if they're "good". However, their idea of "good" is completely up to them. You're trusting that whatever they say is good, is good to you also. But what if my name is Bob Paypa and I want to have an SSL cert for my personal domain, paypa1.com? I would hope Verisign wouldn't allow an obvious phisher to get an SSL cert for paypa1.com, but I also think they shouldn't flat-out reject SSL cert requests just because the domain name resembles another business' name.
Personally, I've never trusted the CA verification system. I see an SSL cert as something that guarantees my connection to that server is encrypted, nothing else. As others have said, if you trust a server enough to connect to it, then you might as well trust a self-signed cert from that server. Would I give them all my bank account info just because they have a cert? No. Would I do regular website stuff via HTTPS using their self-signed cert? Sure.