When Is a Self-Signed SSL Certificate Acceptable? 627
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?"
Interesting (Score:2, Interesting)
"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"
So it exists for the distribution of copyrighted material, right? Just like, say, Amazon? Or like SourceForge? So what's the problem of the CA knowing their personal information? After all, the domain registrar already knows the correct data, right?
Or are you saying that they exist for the distribution of copyrighted material illegally, in which case we all couldn't really care less what their problems are, and you should report them to the appropriate authorities instead of helping them break the law?
Now, back to your main question:
"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!
Self-signed certificates are pointless, because you are confident than no one is listening but you have no idea who are you talking to. It means the possibility of a man-in-the middle attack and many more problems that should be obvious to any self-respecting, computer-literate, intelligent person.
But what is even more important is the problem of getting people used to trusting incorrect, i.e. "self-signed" certificates. When they later are victims of phishing attacks everyone on Slashdot is saying to blame the victims because they have entered the fake bank website with an incorrect SSL certificate, while at the same time forcing equally incorrect certificates down their throats and saying that it is ok to trust it, because it is "self-signed" (which means that it is signed by itself, for those not familiar with the SSL lingo).
And these are the most important problems caused by self-signed certificates. False sense of security, and getting used to the browser complaining about incorrect certificates and ignoring it later.
Can you trust a commercial CA??? (Score:1, Interesting)
In a world of National Security Letters, can a commercial CA located in the US be trusted?
How can we tell if a CA is confirming government man-in-the-middle attacks as being a valid endpoint?
Are you really connected to your site via SSL/TLS, or is there an automated system intercepting traffic and analyzing it using a compromised CA?
In such a world, self-signed certificates, or hosting your own root CA is the more secure option.
I cannot confirm that CA's such as Verisign, Thwart, etc., can be trusted.
Re:Always. (Score:4, Interesting)
Re:Always. (Score:4, Interesting)
I don't know of any instances of SSL certificates being subverted in the way described by the GP, but there are instances of phishing sites using correct-looking certificates, such as http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html [washingtonpost.com]
"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"
Not very easily, but you can use two factor authentication to make sure that even if scammers find out the static username, password, and whatever, it's useless without a second bit of information generated by an electronic device. So the device generates a pin number which is based on time, or generated in a sequence. I have used Cryptocards in the past - they can generate a 7 digit pin number which is valid for one time only - the server knows the order that the card should generate the pin and it can be easily tied into existing infrastructure using by authing using RADIUS. Some UK banks have sent out devices which you need to insert the debit card into in order to generate the code. It's far less likely that the scammer is going to have the debit card, *and* the electronic device, *and* the static username/password.
Re:Always. (Score:5, Interesting)
Re:Always. (Score:2, Interesting)
This is utter nonsense. Either you have been scammed, or you are a scammer.
Let me tell you what a certificate does in its typical web application. It allows you to create an encrypted conversation with the webserver. At the time the certificate was issued, the cert "authority" required money and that you generate what is called a "certificate request", which is an entirely self-generated document containing nothing of interest or particular security. Typically a company name, an address, that sort of thing. Once they have this, they may (or may not) elect to call a phone number you give them and have you record your voice saying your name or some equally insecure thing. At that point, they issue you the certificate.
Once the certificate is issued, it is installed where the webserver software can find it, and if done correctly (not difficult), the webserver will now allow https as well as http, and, because the certificate was issued by an (cough) authority, your browser will not complain.
Because there is literally no after-the-fact checking, you have no way of knowing, other than reputation (which has NOTHING to do with certificates, but with behavior) if you are dealing with a reputable merchant, or hackerboy69. There's nothing stopping hackerboy69 from *legitimately* getting a certificate from a cert authority that gives him ownership of "trusted-e-commerce.com" or some such horsepucky. He can set up a business, operate long enough to esablish trust, and then hose you. Certificate purring along perfectly 100% of the time.
Presuming the victim site is a reputable one, any time after the cert is installed, any rooting attack on the webserver - of which there are endless varieties - that succeeds, will give the attacker complete control over (a) the webserver, (b) the certificate, (c) the ability to enter into an encrypted conversation with your browser.
There's no need for a "man in the middle" attack, nor is there any need for you, as the consumer, to do anything differently. You're simply hosed. You may think that you're talking to secure-as-heck.com, but in reality, you're talking to hacker-boy-69, who has pwned secure-as-heck.com, and who is now gleefully collecting your information.
So why bother? Because the server takeovers are rare; it ranges from fairly easy to difficult to do, but once done, the work to make the server act normal, but actually steal info, that takes more work. Work that is beyond most script kiddies. But again, this has NOTHING to do with the certificate, only with the security of the site in question. If it gets hacked, you're hosed. Doesn't matter if the hack is through the net or via some employee using the root password some dunce taped to the front of the server rack.
The reason that certificates have value is because when you talk to a website, your packets go all over the place as they travel back and forth between the two parties, and a lot of people and machines have a chance to look them over. SSL conversations are about a zillion times harder to do that to -- they read back as garbage -- so people and machines tend to go for the low-hanging fruit instead, the tons of non-encrypted messages that cross the net. Encryption *is* good. I'd much rather not give a credit card number, expiration date, and CCV code in the clear. But I'm under no illusion that I've been protected from anything except during the trip between me and the server I'm talking to, which I hope, but cannot ever prove, is the one I *want* to be talking to.
Once connected to the server, you have to make the same set of assumptions you do in a brick and mortar store. You have to assume the handsome guy behind the counter belongs there
True Story (Score:5, Interesting)
While at DEFCON working the Wall of Sheep one year we discovered that someone had setup a WEB site on the network to bet on the outcomes of the hacking contest - they used a self signed SSL cert. Now some people, being paranoid on a VERY hostile network, turned down this certificate and promptly created\used the WEB site sans SSL - exposing their creds clear text. We promptly snarfed these and posted them on The Wall. 0wned!
All they had to do was accept the cert and they would have been protected. But I guess since seeing that pop-up was out of the ordinary and being on a network that was so nasty they thought they would play it safe and say NO, how stupid....
Re:Always. (Score:5, Interesting)
I figured that would probably happen, but i'd never actually seen it. I don't make a habit of deliberately visiting phishing sites though.
I've not seen a bank do it, but these guys [melbourneit.com.au] do, which I think is just insane, especially seeing as in all other respects (apart from price) they are an excellent domain registrar. Click the login link in the top left and you'll be presented with a non-https page with a username and password on it. I've emailed them about it but they just don't get it. Idiots.
I've stopped using MelbourneIT for new registrations on that basis. I suggest you do the same.
Comment removed (Score:1, Interesting)
Re:Interesting (Score:2, Interesting)
On the flip side, if you accept a self-signed cert the first time, and it does turn out to be bogus, the only person liable for that is you the user. Thats why browsers warn against it. Self-signed certs ONLY acceptable for encrypting traffic to an entity that you have first hand knowledge you can trust. i.e. SSLing admin functions of a website I control and run with a self signed cert, or using https to get in to my uTorrent client from work.
Re:Always. (Score:2, Interesting)
"2) Some banks have login forms on un-encrypted pages"
The login page can be un-encrypted as long as the data from the form on that page is encrypted before it is sent over the Internet. Said another way, as long as the form action is "https://mybank.com/etc" there is no problem. The only reason some banks encrypt the login page is to make the customer feel good; it doesn't increase their security one iota.
Re:Always. (Score:5, Interesting)
Wachovia tells their users to enter their credentials on the unsecured front page, which then submits to a secure script processing said credentials.
What you might be forgetting: What if I set up interception on my shared WiFi (or somewhere at the backbone of the hypothetical ISP I might be working for) to grab all HTTP requests for / going to r3wec01.wachovia.com and add a tiny bit of JavaScript that, in addition to the page working as it usually does, posts all keypresses to a script of my choosing?
Without access to WB's certificate, I couldn't do that on a properly secured HTTPS site. Thanks to unencrypted HTTP, it's pretty [eff.org] trivial [wired.com].
Re:Always. (Score:2, Interesting)
The SSL certificate scheme is there to assure your browser (you) that the bank is who they say they are.
That's not what it does, though.
The only thing it does is to assure you that the bank says they are who Verisign says they are. Equating that to the bank actually being who they say they are, requires infinite trust in Verisign and their honesty.
Why should anyone trust Verisign? What reasons do we have to trust them? Not "to not trust them", trust needs to be earned.
If we can't even trust them not to ruin DNS, how can they ever reach the level of trust needed for certificates? Does the word "sitefinder" ring a bell? Verisign has already demonstrated that we can't even trust them not to ruin DNS, and certificates need a much higher level of trust.
Then tell me... If I'm the victim of a MITM-attack, why would I even care if Verisign says that the attacker is my bank or not? He's still going to copy the entire encrypted transactions either way.
Re:Always. (Score:3, Interesting)
But that's nonsense. I have been robbed by the SSL certificate companies so that my shopping cart page would not flag any browser warnings. I paid my money and had the certificate the next day. They didn't contact me by phone or snail mail. The most they could've done is verified that the business name I gave them was an actual business--but there's no way they could have verified that I was authorized to request a certificate on behalf of the company.
In short, the whole idea that SSL certificates come anywhere close to proving that a website is who it says it is is nonsense. Only a fool would trust that to be true.
SSL certificates are organized theft and are a racket.
StartSSL free certificates (Score:2, Interesting)
There's no reason to continue to use self-certificates today as you can easily get your certificate signed for free by http://startssl.org/ [startssl.org]
Their certificate authority is included by default with Firefox (you can add it manually with IE)
You can get a certificate recognized by default by the majority of browsers for a few bucks anyway.
Just make sure you have OSCP checking turned on on your browser (because it's so easy to sign a certificate that it has to be revocable easily)
Please also stop to use pre-computed certificates (ie localhost with a private key on a cdrom that everybody can get...) or reuse the same on different servers (in some cases, Firefox 3 now refuses to load them...)
Re:Mod parent DOWN, please (Score:3, Interesting)
No, it doesn't! It ensures that the server that you are connected to has a cert with the name of the domain on it. It could have been signed by any of the many CAs in the browser's list. Perhaps the real site has another cert with that domain name on it signed by another CA, but you won't know that.
The system is only as believable as the least conscientious CA in the list.
RTFWP or just search ... PLEASE! (Score:3, Interesting)
Applied Security Technology will always meet the expectations of experience.
http://en.wikipedia.org/wiki/Pretty_Good_Privacy [wikipedia.org]
http://en.wikipedia.org/wiki/OpenPGP#OpenPGP [wikipedia.org]
http://en.wikipedia.org/wiki/Public_key_infrastructure [wikipedia.org]
http://en.wikipedia.org/wiki/Certificate_authority [wikipedia.org]
http://en.wikipedia.org/wiki/Philip_Zimmermann [wikipedia.org]
http://en.wikipedia.org/wiki/Secure_Sockets_Layer [wikipedia.org]
http://en.wikipedia.org/wiki/Secure_Sockets_Layer#TLS_handshake_in_detail [wikipedia.org]
http://en.wikipedia.org/wiki/Hardware_token [wikipedia.org]
http://en.wikipedia.org/wiki/Biometric_authentication [wikipedia.org]
https://www2.sans.org/reading_room/ [sans.org]
http://www.giac.org/certified_professionals/practicals/gsec/4993.php [giac.org]
http://www.giac.org/certified_professionals/ [giac.org]
http://www.linkmatrix.de/index.php?education=home [linkmatrix.de]
http://www.linkmatrix.de/tutorials.php?q=PGP [linkmatrix.de]
Those that can DO, read. Those who can read, but not DO, preach.
Readers, fakers, and test-takers always manage to fail.
Hands-On experience and continuous-learners always work for tale (or is that rep).
To many PGP/PKI/CA/TSL... comments are cross-BS technology application comments. Only in politics does mixed pieces of BS function properly or as expected.
In technology as in science it either does, or it don't do. There is working properly or working poorly (with a problem) until troubleshot and fixed. If it never worked or ain't working at all (cannot be made to function fully and consistently as expected) then someone fycked-up bad (miss-applied technology application) perhaps the brown-nose wannabe manager that can only read made a decision.
Works for me (Score:3, Interesting)
Self-signed certificates work great, provided you require users to install your CA certificate as one of the trusted certs in their browser.
We make our CA certificate available at a simple url (https://www.example.org/ca/) that uses a commercial certificate signed by a "real" CA, and provides an explanation and instructions on how to install our cert. Installation is straightforward in IE and Firefox, a little trickier in Safari.
Once our CA certificate is in the browser's trusted list, all of the other certs are trusted as well. The only thing to watch out for at that point is name mismatch issues caused by domain aliases and the like.
We considered publishing our certificate thumbprints, too, but that just seemed too paranoid.
Verifying the key out of band (Score:3, Interesting)
>personally verified key signatures face-to-face.
Over the phone is probably adequate. You already know your bank's phone number. Incidents of phone numbers being rerouted are rare, though there are rumors of escort services in Las Vegas redirecting traffic meant for their competitors, and Florida's probation department once had their phone number remapped to a phone sex service in New York.
Over the phone, you'd just have the website operator read you the thumbprint for their cert. You could check it against the value shown in your browser.
Someone more mischievous than me should call up a bank and say "I'd like to verify the SHA1 hash of your X.509 certificate" and report on the results.
A realistic compromise is to note the thumbprint the first time you visit a site, hope it wasn't taken over at that instant, and then make sure it's the same next month when you visit again.