Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

When Is a Self-Signed SSL Certificate Acceptable?

kdawson posted more than 6 years ago | from the how-about-never-is-never-good-for-you dept.

Encryption 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?"

cancel ×

627 comments

Sorry! There are no comments related to the filter you selected.

Always. (5, Informative)

fyngyrz (762201) | more than 6 years ago | (#23931473)

SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate.

They do not, and never been able to, provide any verification of who is on either end. This is because literally one second after they are issued, regardless of the level of effort that goes into validating who is doing the buying, someone else can be in control of the certificate, legitimately or otherwise.

Now, I understand perfectly well that Verisign and its brethren have made a huge industry out of scamming consumers into thinking that identification is indeed something that a certificate provides; but that is marketing illusion and nothing more. Hokum and hand-waving.

hipotesis (1, Insightful)

alxtoth (914920) | more than 6 years ago | (#23931507)

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

Re:hipotesis (5, Insightful)

Anonymous Coward | more than 6 years ago | (#23931645)

It's not really a No No; it's just that, in order to be sure that the certificate is okay, you have to be able to ensure that you have the same level of security as a normal certificate. What is that exactly??

Well, a normal certificate is often verified simply by email. In order to get one you have to prove that you can respond to email for your domain. In other words you prove that you get IP packets that are destined to that domain (recieve the email you want). This is quite a bit harder than spoofing, but much easier than breaking an RSA key.

So, how can we get the same level of security? Well, if we connect to a web server then that web server has proven that it can get the packets for that domain. Any certificate it distributes has almost the same level of security as a normal web certificate. There is one difference. When you use a normal certificate they are proving that they can now recive your packets and they could at another time much earlier when they contacted the cerfificate authority. Minor seeming, but important difference. You can gain the equivalent security by checking that the certificate is the same as it was some time before and checking that you have the same certificate as other people world wide.

So a good way, would be for the web site you are posting about to post their certificate fingerprint on various public web sites and news groups known to be associated with them. That would be just as good as a normal web certificate. Or put another way, given the amount people pay for them and the security they advertise, normal certificates are indeed scams.

Please note, this discussion doesn't cover extended verification which is also a partial scam, but not as bad as normal certificates. Please note also, that there are some of the older certificates which also require more than just email verification. That is totally irrelevant since your browser interface doesn't differentiate between them and the hackers will always go for the weakest security.

Re:hipotesis (3, Informative)

Anonymous Coward | more than 6 years ago | (#23931701)

I don't see why they can't apply for a "real" cert.

Quite a few CAs these days use only email to verify that you are entitled to the cert (usually obtained via whois records). Some of them do it for free (cacert.org, although the CA cert is not trusted by many browsers).

I'd be happy to trust a cacert.org CA certificate, but *not* some random CA who could then issue certificates for other sites.

Re:hipotesis (3, Insightful)

master5o1 (1068594) | more than 6 years ago | (#23931927)

What he's saying is that it is not necessary for all websites that would like SSL security to have to have a proper commercially signed certificate. For something that is less-risk than a bank they should be allowed to self-sign.

Re:Always. (5, Insightful)

jamesh (87723) | more than 6 years ago | (#23931539)

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 wonder... (1)

hummassa (157160) | more than 6 years ago | (#23931631)

If someone does an inside job of compromising a bank's certificate, how much time would you think the certificate would be on the wild without being revoked? I bet enough time to do a lot of damage.

Re:I wonder... (4, Insightful)

jamesh (87723) | more than 6 years ago | (#23931669)

If someone does an inside job of compromising a bank's certificate, how much time would you think the certificate would be on the wild without being revoked? I bet enough time to do a lot of damage.

Not nearly as much damage as would have been done if everyone used self-signed certs. Look up 'man in the middle' attack.

Re:I wonder... (5, Insightful)

evilpenguin (18720) | more than 6 years ago | (#23931715)

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.

Re:I wonder... (1)

iivel (918436) | more than 6 years ago | (#23931833)

All of my certificates on this workstation start with DoD ... and I had to put them there myself. Now on my laptop, it's whatever came pre-installed from HP. I may have to have a look at that later...

Re:Always. (3, Interesting)

chowells (166602) | more than 6 years ago | (#23931793)

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. (5, Interesting)

bpkiwi (1190575) | more than 6 years ago | (#23931939)

My bank txts a one time authentication code to my phone for any transaction that involves money leaving my accounts (transfers, setting up direct debits, etc). I've always considered it an elegant solution, not foolproof, but few systems are.

Re:Always. (5, Informative)

the_womble (580291) | more than 6 years ago | (#23931905)

I doubt that precise attack has been used, but:

1) SSL certificates do get issued to phishing sites
2) Some banks have login forms on un-encrypted pages

see: http://news.netcraft.com/archives/2005/12/28/more_than_450_phishing_attacks_used_ssl_in_2005.html [netcraft.com] and http://it.slashdot.org/article.pl?sid=06/02/13/2143251 [slashdot.org]

Re:Always. (0)

Anonymous Coward | more than 6 years ago | (#23931919)

Can you cite any examples of a case where a certificate has been subverted in this way?

There are many, mostly not published, but probably the most important one which is publically know, because you could have done anything you wanted with it to most of the computers in the world, is this one [amug.org] . Note that the posting is actually about ongoing security problems related to the hole.

Second in importance to that are the many certificates created with debian for which the private key is insufficiently secure and can be derived from the public key.

You should note, that even though there have been such issues, I belive that no SSL warantee has payed out ever, which gives you some idea how much they are really worth.

Re:Always. (5, Insightful)

jolyonr (560227) | more than 6 years ago | (#23931559)

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

Re:Always. (0)

Anonymous Coward | more than 6 years ago | (#23931587)

The internet would be FAR more secure if there was a way of using self-signed certificates without browser warnings
So exchange certificates manually with the self-signer that you trust (perhaps in person) and import into your browser manually?

Re:Always. (0)

jamesh (87723) | more than 6 years ago | (#23931639)

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".

Being the internet, i'm not quite sure that this isn't sarcasm, but i'm going to pretend it isn't.

Encryption is only a small part of the idea of certificates. The main part is that it gives you, the user, some idea that the web site you are typing your credentials into is who you think it is (eg your bank) and isn't someone else pretending to be your bank.

Encryption is all well and good, but a simple keystroke logger subverts all encryption on the wire, so it doesn't add that much value.

If your bank had a self signed cert, I could create a self signed cert that looked similar enough that most people couldn't spot the difference, and then I could fiddle with the dns settings on the internet cafe that I run (i don't really run an internet cafe, just go along with me), and make you log into my pretend bank website instead. I wouldn't need to do anything to the laptop you brought with you to pull this off.

Look up 'man in the middle' attack if you want to know more.

(or just ignore me if you were being sarcastic and I completely missed the point :)

Re:Always. (2, Interesting)

fyngyrz (762201) | more than 6 years ago | (#23932003)

Encryption is only a small part of the idea of certificates. The main part is that it gives you, the user, some idea that the web site you are typing your credentials into is who you think it is (eg your bank) and isn't someone else pretending to be your bank.

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 and isn't standing over the (virtual) body of the proprietor. You have to assume that the nameserver at your ISP hasn't been subverted and is now directing you to an amazon.com that *isn't* amazon.com, where they have lifted the SSL certificate from amazon via a hack and are now having your info for lunch.

Because these certificates do NOT guarantee IP's; just names. You got your name from your nameserver; if that is compromised, the names it serves you could be anywhere, at any IP, and the certificate will continue to work perfectly. In such a case, amazon (the real amazon) wouldn't even know there was anything wrong, because they still have a 100% working server, taking orders, etc. The subversion isn't taking place through them. Just a bunch of people using the compromised nameserver.

I could move our secure server to a new IP in a few seconds; it's a tiny edit of a few files. The certificate would work just the same at the new location. So if I can do it, so can anyone who can get root. Uncomfortable fact for you: People get root all the time.

There is a fairly long list of attack modes similar to this; in all cases, an encrypted connection can be established without any trouble.

SSL certificates encrypt conversations. Certificate authorities prey on fear and install a completely false sense of security. Browser authors are in cahoots with the cert authorities. Those are the three key truths about SSL that a truly savvy consumer understands.

All you can do is look around and see if the site seems to be the site you think it is. If the site has personal info of yours, and *it* can tell *you* that info, then either you're in the right place, or the whole server has been subverted. It can happen. No way around it. It doesn't even help to stick with big places like Amazon; they may have great technical people and be hard as heck to crack, but they are much more *worth* cracking, and so no doubt eventually, the odds favor someone pulling it off. On that day, your order for your new camera isn't ever going to ship. By the time you figure that out, hackerboy69 will probably be on a beach somewhere, sipping a mai tai, and smiling like a crocodile.

But the net is huge and it is kind of like pickpockets... they're always out there, but the odds favor you never running into one. Most of the technically competent are too busy leading reasonable lives to bother buying into some ethics-free lifestyle or business - like a certificate authority.

How so? (1)

Chuck Chunder (21021) | more than 6 years ago | (#23931813)

ALL sites would be more secure with a self-signed certificate than plain HTTP

How so? Both are susceptible to a man in the middle attack. In the self-signed certificate scenario the man in the middle merely needs to generate their own self-signed certificate.

That's slightly more complicated but not enough to deter anyone if the information is even vaguely snoop-worthy.

I agree however that the certifying authorities are largely rip-off merchants.

Root on CD (1)

tepples (727027) | more than 6 years ago | (#23931969)

In the self-signed certificate scenario the man in the middle merely needs to generate their own self-signed certificate.
Not if the bank has already given me a copy of its root certificate on CD when I opened my account.

Re:How so? (0)

Anonymous Coward | more than 6 years ago | (#23932029)

Encryption without authentication protects against passive snooping (but not against active attacks). Plaintext communication does not protect against passive attacks.

With wiretapping legislation being passed around the world, default encryption would at least require active, packet-altering attacks, which could be detected by interested parties, whereas passive snooping is practically undetectable.

It would indeed be beneficial if browsers always tried establishing SSL connections and treated connections with self-signed certificates exactly like plaintext connections.

Re:Always. (1)

spottedkangaroo (451692) | more than 6 years ago | (#23931885)

For casual uses, you can get a really basic cert at godaddy for $10. I fail to see why that's so bad. The CAs really do check your identity for the $100 certs and that takes personnel and resources. I fail to see why that's so bad.

Re:Always. (0)

Anonymous Coward | more than 6 years ago | (#23931657)

Rubbish. Self signed certificates provide no guarantees of protection whatsoever if the internet is the only way you're contacting the company. Not even protection through encryption. Using self signed certs, if the initial certificate is man in the middled the encryption is broken. PKI fixes that - using a CA ensures that if you're speaking to https://www.google.com/ and the certificate is signed then you are speaking to https://www.google.com and are not being man in the middled.

Re:Always. (3, Interesting)

Yvanhoe (564877) | more than 6 years ago | (#23931665)

Am I saying something stupid or aren't company like Verisign providing a good way of preventing people doing man in the middle attacks on SSL ? Agreed, it is far from perfect, but with a self-signed certificate, what is to prevent a clever sysadmin to do mitm attacks ?

Re:Always. (1)

EkriirkE (1075937) | more than 6 years ago | (#23931871)

They don't/can't protect from man-in-the-middle, they simply provide an accepted known signature that tells the browser that the site('s cert) is verified authentic, vs, say, a DNS hijack with a X-signed (self or otherwise) cert that, unless alerted about funny goings-on, a user would see that security blanket of a lock icon and submit personal info.

Ex: www.ebay.com gets hijacked, the jackers don't have the true private cert, so they create their own. The browser doesn't recognize the granter as a CA it alerts and warns, etc. A small fraction of personal data gets protected - i say small because i think most of the idiots in the inter tubes would just continue on their merry way "Goddamnit, get me to ebay already" *OK* *Yes* *Accept*

Re:Always. (1)

dreamglider (1314003) | more than 6 years ago | (#23931677)

Certain web-hosting control panels support multiple links through which you can gain access. The server IP address, the customer domain or the server hostname can be used for logging in and in that case the certificate cannot apply for all hosts. Some of the customers are used to logging in using either of the links and the only solution is to force a redirection which causes a small rebellion. In this case a self-signed certificate saves the day at the expense of browser warning.

Re:Always. (1)

pairo (519657) | more than 6 years ago | (#23931679)

The same argument can be said about any kind of identification method. Any form of ID can be forged, the documents presented to get one can be forged, so I don't really see the point in singling out SSL.

Re:Always. (5, Informative)

squiggleslash (241428) | more than 6 years ago | (#23931725)

SSL certificates perform two functions: they verify the credentials of the website you're connecting to, and they provide a secure key for communications between the webserver and you. The reason we combine the two into one certificate is to make man-in-the-middle attacks more difficult. As you suggest, there are ways to compromise the SSL system, however they require you attack in one of four specific places:

  1. You compromise the web browser, providing a bogus list of authorities. Your web browser maker becomes liable in that instance.
  2. You compromise the SSL certificate authority, creating a bogus certificate signed by the CA. In this instance, the authority is liable
  3. You compromise the certificate holder, stealing the legitimate private certificate and redirecting traffic to and from their servers to your own (or hacking into their website to transfer the information to you.) In this case, the holder is liable
  4. You compromise the user's PC, patching the web-browser to accept bogus credentials. In this case the user is at fault

At this point it should be obvious what the SSL certificate system provides you with, which is a clear chain of responsibility for breaches in security. Simply sticking a box between a client victim and server victim is not enough, you have to actively compromise one of the four groups above in order to spy on secured traffic. This creates incentives for each group to keep their part of the chain of accountability secure, and it ensures there's a starting point should there be a breach anyway.

Given the difficulty of sending legitimate certificates directly to participants on a mass scale, the CA system is about as secure as we're going to get, and while it's not perfect, that's not a legitimate reason to treat it equally with unsigned certificates. The chain of accountability makes a difference in terms of how you can recover from security breaches, and the likelihood of there being a breach in the first place.

Re:Always. (1)

TractorBarry (788340) | more than 6 years ago | (#23931993)

> 4. You compromise the user's PC, patching the web-browser to accept bogus credentials. In this case the user is at fault

I think point 4 should really read:

"4. You compromise the user's PC, patching the web-browser to accept bogus credentials. In this case the *users operating system* is at fault."

Re:Always. (0)

Anonymous Coward | more than 6 years ago | (#23932113)

But they don't tell you you are connecting to the site you intend to.
There is no accountability. Are you suggesting I can successfully sue Verisign because I get suckered into visiting a site with a certificate signed by Verisign that looks similar to some other site I am used to visiting?
We would be much better off if browsers saved the certificates of each site we visited and let us know when we went to a site we hadn't visited before or when the certificate of a site we had visited had changed. In those cases information about the certificates could be displayed including information about CAs that had signed the certificate.
The current system is a protection scam that serves the CAs (mostly Verisign) and the browser manufacturers.

Depends. (2, Informative)

Anonymous Coward | more than 6 years ago | (#23931741)

A symmetric cypher combined with a random key provides the encryption. The rest of the system is only there to ensure that the parties who have the key are actually the endpoints, and that necessarily includes the authentication of their identities. The possibility that the certificate owner may not have been sufficiently diligent with his secret key is a problem which all cryptographic systems share. Nevertheless, identity verification is important for protecting against trivial man-in-the-middle attacks and certificates or trust-webs are ways to perform that verification. They're not perfect, but they're the best we have for encryption between mutual strangers. If the other party cannot be trusted to properly handle cryptographic keys, you might almost just as well not encrypt at all.

If you store the public key, then a verifiable signature is still important when the web site's public key changes. (That includes the first connection when you change from no key to the current public key of the web site.) The alternative would be to establish a different trusted channel for key verification. That could be a phone call, if it's sufficiently unlikely that you'll end up talking to the same man-in-the-middle who tries to pass his key as the web site's key. Just reading the self-signed certificate and clicking OK? You could be talking to a third party and would only notice when they stop intercepting connections between you and the web site.

Control of the certificate? What about the key? (1)

Chuck Chunder (21021) | more than 6 years ago | (#23931761)

This is because literally one second after they are issued, regardless of the level of effort that goes into validating who is doing the buying, someone else can be in control of the certificate, legitimately or otherwise.

What do you mean "control" of the certificate?

The certificate isn't secret information, it's sent publicly at the start of every ssl request.

The private key is the part that means only the proper person can establish an SSL connection certified by that certificate. Incompetence aside there is no reason that should fall in to the hands of someone unauthorised.

If you add an exception for a self-signed certificate then you basically have to trust that the first time you hit a site you aren't being hit by a man in the middle attack.

With a CA-signed certificate then you are basically trusting the CA has done at least some (even if it's only domain control) authentication.

Verifying SSL keys the way you verify SSH keys (1)

tepples (727027) | more than 6 years ago | (#23932031)

This is because literally one second after they are issued, regardless of the level of effort that goes into validating who is doing the buying, someone else can be in control of the certificate, legitimately or otherwise.
What do you mean "control" of the certificate? [...] The private key is the part that means only the proper person can establish an SSL connection certified by that certificate.
Incompetence that leaks the private key can happen faster than you might expect.

If you add an exception for a self-signed certificate then you basically have to trust that the first time you hit a site you aren't being hit by a man in the middle attack.
It's a little bit harder for an attacker to make a man-in-the-middle attack if the owner of a self-signed certificate reads you the certificate's fingerprint over the phone, no?

Re:Always. (1)

spottedkangaroo (451692) | more than 6 years ago | (#23931865)

I disagree 50%. In practice, this is correct, but in theory it is not.

Theoretically, the CA is actually checking the identity of the orgs they sell certs to. Most actually do this to a limited extent.

Also, each of the CAs keeps a revocation list for certificates that got out of reach. In order for someone to use the certificate illegitimately, they have to gain control of the domain name *and* the certificate -- or simply the web-server I suppose.

If no major security breach is *currently* in progress, but one happened in the past, theoretically, you could simply revoke the certificate and get a new one.

The revocation works, but the problem is that nobody actually checks the revocation lists. I was going to link to it, but presently I can't even find the CRL for verisign...

CRL (knowledge) [verisign.com]

Perhaps I'm just wrong and the CRL is built into my browser... I don't think so. I seem to recall actually clicking on a bunch of them to tell firefox to go check them nightly.

Yeah, in ff3 it's prefs->advanced->encryption->[revocation lists] -- mine is empty. Heh. Fat lotta good that does.

Re:Always. (1)

William Robinson (875390) | more than 6 years ago | (#23931943)

SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate.

IMHO, No. It does provide many other features including identification of the two machines talking to each other.

They do not, and never been able to, provide any verification of who is on either end. This is because literally one second after they are issued, regardless of the level of effort that goes into validating who is doing the buying, someone else can be in control of the certificate, legitimately or otherwise.

Again, IMHO, wrong. You can not take certificate issued to one party and, use it on other server, and make that server pretend as original server.

Digital certificates contain a lot of information including public key of the machine you are interested to communicate. Unless you get hold of private key of the machine in question, that certificate is useless on any other machine. And if you have enough access to the machine to steal private key, the security of machine is already compromised, no need to blame Digital Certificates.

If it would not have been this way, anybody would have been billionaire, using man-in-middle attack, by installing a machine in between client and server.

Self signed certificate are useful as test tool, before you are satisfied with your setup, and before you decide to invest in a globally acceptable Digital Certificate signed by a good CA like Verisign or Thwate.

Correct me if I am wrong:)

Bravo, plus some info on Enigform (1)

buanzo (542591) | more than 6 years ago | (#23932075)

Bravo, bravo!

http://maotest.buanzo.org/ [buanzo.org] (some stuff with OpenPGP for HTTP, secure session initiation, etc)

Re:Always. (1)

vrillusions (794844) | more than 6 years ago | (#23932089)

Remember the story not too long ago about a XSS vulnerability that essentially let you display your own content on an EV certified SSL page? Even a $500+ certificate can't protect against buggy sites. One of the bigger annoyances with firefox 3 is what happens when you go to a site with a certificate that is not valid (self-signed, untrusted CA, expired, etc). You see a page styled similar to the server not found messages. You then have to click on like 4 things with one of them saying that its really bad to do this, etc before you can continue. The time where "valid" certificates I'd encourage are for sites that do payments in some way. Imagine if your bank was suddenly using a self signed cert for login? I've used http://cacert.org/ [cacert.org] for years now for the various admin sections of sites. Browsers still don't recognize it as a real ca but adding them is trivial and they are listed in the latest editions of most Linux distros. Its nice not having to add exceptions for all these certs, but can't make self signed ones that last 10 years either

Interesting (2, Interesting)

Mensa Babe (675349) | more than 6 years ago | (#23931501)

"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.

Re:Interesting (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23931667)

because it is "self-signed" (which means that it is signed by itself, for those not familiar with the SSL lingo).
Gee, thanks for solving that mystery for the rest of us!

Re:Interesting (5, Insightful)

locofungus (179280) | more than 6 years ago | (#23931691)


"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.

Re:Interesting (1)

marco.antonio.costa (937534) | more than 6 years ago | (#23931699)

I thought SSL encryption was about secure comunications ( that armored vehicle you're talking about ), not who is authorized to do what. By the way, anyone stupid enough to give their money to such a truck in the fable you spinned up deserves to have it gone.

When they are later victims of phishing attacks everyone on Slashdot will laugh at them for entering their bank account and password into a site that reads www-we-will-screw-you.mybank.com.

And that is the most important problem caused by third-party signed certificates. False sense of security and paternalistic gov't-like measures that make encryption look like a privileged tool for the ruling elite, and not mere mortals.

Re:Interesting (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23931801)

By the way, anyone stupid enough to give their money to such a truck in the fable you spinned up deserves to have it gone.
You do realise that the WHOLE FUCKING POINT was that it would be stupid to do so, right? Idiot.

Re:Interesting (5, Insightful)

Znork (31774) | more than 6 years ago | (#23931773)

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.

Re:Interesting (1)

wrook (134116) | more than 6 years ago | (#23931777)

"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?

There is a big difference between knowing who I'm talking to and knowing that I'm talking to the same person I talked to last time. Most of the time I don't care about the former. Do I care that an author is who they say they are? Or do I care that they wrote a specific book?

Most of the time relationships (especially on the internet) are not dependent upon the actual identity of the person I'm talking to. They rely on the history that I've had with that person. And there are many times when I might want to have a secure conversation with someone, knowing that they are the person I talked to the day before. But I usually don't care what their identity is.

In the case of a sales transaction, I agree that knowing the identity of the person is useful (i.e., I know who to chase if the sale goes wrong). But to say that there are no cases where I want to have continued secure conversations with someone without knowing their identity is just plain wrong.

To give you an example, let's suppose I downloaded a piece of software off the internet. I notice that there is a patch to the software. I want some security that the patch is being distributed by the same person I got the software from in the first place. I have no interest in knowing that person's name, where they live, etc, etc, etc. I have a trust relationship with them already and I simply want to continue it.

Re:Interesting (1)

tepples (727027) | more than 6 years ago | (#23932097)

There is a big difference between knowing who I'm talking to and knowing that I'm talking to the same person I talked to last time. Most of the time I don't care about the former. Do I care that an author is who they say they are? Or do I care that they wrote a specific book?
If you have a printed copy of the book, how do you verify that the errata web page listed in the book is in fact under control of the author or publisher? CA-signed SSL certificates help you connect an off-web identity to an on-web identity.

Re:Interesting (1)

ren-n-stimpy (230862) | more than 6 years ago | (#23931795)

no, the answer is not "never." it is a convenient, extremely user-friendly way to provide encryption when authentication has occurred via a different channel/method.

Re:Interesting (1)

dave420 (699308) | more than 6 years ago | (#23931799)

I have to disagree. SSL certificates, regardless of who signed them, are a matter of trust. This site just wants the trust put it in (and not a CA), which you would be willing to do if you wanted to use the site in the first place. Getting all pissy about it like some petulent 8-year-old doesn't change that.

Re:Interesting (1)

kestasjk (933987) | more than 6 years ago | (#23931819)

Self-signed certificates are pointless, because you are confident than no one is listening but you have no idea who are you talking to
Once you accept a certificate you can be sure that, from that moment on, you are talking to the same person you were talking to when you first accepted the certificate.

So you can take special measures to ensure that the self-signed certificate is valid, that VeriSign might take themselves with a CA-signed certificate, and from then on you can be sure that you're safe.

So it can be less convenient, but if people know what they're doing (not always the case) it can be just as secure as a CA-signed cert, and it is always more secure than no cert at all. (Which is the most important point, I think)

Re:Interesting (1)

mystik (38627) | more than 6 years ago | (#23932013)

"When is it acceptable to encourage users to accept a self-signed SSL cert?" The answer is: Never.

You realize, however, that this is exactly how SSH works?

The first time you connect to an ssh server, the server sends out it's key. It's self-signed key. And the client polietly asks you "Would you like to accept this key?, here is it's fingerprint" It's now the *users* responsibility to trust that key, via some other secure channel or web of trust. *This* is the only opportunity for a MITM attack, even in SSH.

From that point on, the key is saved, and the ssh client complains loudly when something goes wrong with it.

Self-Signed Certs behave in exactly the same manner. If this site can provide a secure channel to advertise it's correct self-signed key fingerprint, and users cache + save that key, then they get exactly the same kind of security they'd get with ssh.

I do question, however, their decision to use mismatched certs + site names. This will cause the browser to throw up a warning regardless of whether it's cached or not, which will probably desensitize users to the severity of these kinds of warnings.

Not really (1)

John Betonschaar (178617) | more than 6 years ago | (#23931503)

It's only giving a false sense of security if people do not trust your web site. If the certificate authority is setup well, the server certificates are created from it like they should, and the certificate authority server is secured well enough (ie: not accessible from the outside in any way) the setup is in no way 'less safe' or trusworthy than using a known certificate authority. It's not like anyone can fake your CA or the client certificates.

Re:Not really (0)

Anonymous Coward | more than 6 years ago | (#23931541)

If the certificate authority is setup well, the server certificates are created from it like they should, and the certificate authority server is secured well enough (ie: not accessible from the outside in any way) the setup is in no way 'less safe' or trusworthy than using a known certificate authority.

That's a huuuuge IF...

Re:Not really (1)

evilbessie (873633) | more than 6 years ago | (#23931909)

But how do we know that a 'random' CA is trustworthy, what is to stop disreputable companies having their own CA. The point is to give some degree of trust to the system which otherwise could not be trusted. It may be badly managed at the moment or the companies may try to screw you over, but that doesn't stop it being a good idea to have some degree of trust when using certificates.

Re:Not really (0)

Anonymous Coward | more than 6 years ago | (#23932011)

It makes me wonder why there isn't some sort of caching thing, like with SSH.

If your cert is signed by a root CA then just cache it without complaining, otherwise warn the user then cache it if they want.

If it changes after caching then complain.

Wouldn't something like this be a better prevention against man-in-the-middles with signed certs? Or do certificates change so frequently that it would just get annoying?

But then, who reads pop-ups anyway?

Can you trust a commercial CA??? (1, Interesting)

Anonymous Coward | more than 6 years ago | (#23931517)

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:Can you trust a commercial CA??? (0)

Anonymous Coward | more than 6 years ago | (#23931763)

Also, as navigation is performed via FQDNs, there is an additional issue of compromised root DNS systems.

Compromise the CA and root DNS system and you have an instant eavesdropping setup.

Since all these would be under US control and the push for interception of voice and data, I'd say it is a well established practice.

The question is what threat does that pose to foreign governments and businesses?

where's the article? (1)

stormguard2099 (1177733) | more than 6 years ago | (#23931533)

Geez, I bet none of you even RTFA before you posted;)

Re:where's the article? (1)

marco.antonio.costa (937534) | more than 6 years ago | (#23931707)

Of course I didn't. This is /., isn't it? ;)

For Testing Only (1)

Ammin (1012579) | more than 6 years ago | (#23931553)

IE 7 on Vista and Firefox 3 on Windows will only accept certs using RSA encryption from trusted authorities. The process for adding a trusted root authority in either browser is not particularly user friendly. So if you want anyone but geeks to actually use your site with modern browsers, you really have to get your cert signed by one of the default trusted root authorities.

Re:For Testing Only (0)

Anonymous Coward | more than 6 years ago | (#23931845)

StartCom Ltd is a trusted root authority in Firefox 3 (and their earlier root cert is in Firefox 2 and Safari 3). They provide free SSL certificates at http://www.startssl.com/ [startssl.com]

This story reads like... (1)

The Ultimate Fartkno (756456) | more than 6 years ago | (#23931567)

...O.J.'s "If I Did It, Which I Didn't, But Could Have, And Might Have, And Probably Did, But You Can't Prove It, And After All The Bitch Was Really Asking For It, But That's No Big Deal And I'm Going To Go Play Some Golf" manuscript.

No links, no research, no facts, just a gripping headline that has nothing to back it up other than claiming that "a certain web site" did something.

That's some great detective work, Lou...

Trivial question - how about the math answer ? (5, Informative)

OeLeWaPpErKe (412765) | more than 6 years ago | (#23931571)

Self-signed certificates are acceptable if you can spread the root public key *yourself* in a secure manner.

Simple, no ?

In any exchange between 2 known parties for example, it is *always* preferable to have self-signed certificates.

Internally (1)

jamesh (87723) | more than 6 years ago | (#23931577)

Only internally, when you have rolled out your trusted root cert to all the users who might access you site (in a secure manner of course).

Or during testing when you have dev.mywebsite.com that you are giving selected users access to for debug and testing purposes. But the cost of a dns validated cert is so low that you might as well just fork out the $$$ and put a proper cert on it anyway.

Development uses only (2, Insightful)

JenniP (824070) | more than 6 years ago | (#23931583)

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.

Requirement for a signed certificate SSL flaw (5, Insightful)

Chrisq (894406) | more than 6 years ago | (#23931591)

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 [wikipedia.org] , 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

Re:Requirement for a signed certificate SSL flaw (2, Informative)

wtanaka (13113) | more than 6 years ago | (#23931807)

Isn't any encrypted communication without some form of identification susceptible to man in the middle attacks?

Re:Requirement for a signed certificate SSL flaw (0)

Anonymous Coward | more than 6 years ago | (#23931893)

Yes they are.
However it's an order of magnitude at least more difficult to perform a man in the middle attack than to simply observe the data from the network.

I wouldn't want to trust sending complex financial information with an unknown self signed certificate but I'd be happy to use it for privacy reasons for example. I would guess that a self signed certificate makes it 100 times more difficult to intercept your data than using no encryption. A proper CA signed certificate makes it 100 times harder again.

Re:Requirement for a signed certificate SSL flaw (1)

asc99c (938635) | more than 6 years ago | (#23931843)

In my opinion SSL mixed two requirements, identification of site owner and secure communication.
Well that is really just because the way public key encryption works provides both of these. The identification might not be required, but it's there anyway.

This has got to be.. (0)

Anonymous Coward | more than 6 years ago | (#23931595)

..the most stupid reader's question ever to get posted.

It's at least as secure! (2, Insightful)

locofungus (179280) | more than 6 years ago | (#23931599)

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.

The site is (0)

Anonymous Coward | more than 6 years ago | (#23931611)

http://what.cd/ [what.cd] - the private music torrent tracker that spawned after oink.me.uk/.cd was taken down by the British police last year.

Tons of them (5, Informative)

evilpenguin (18720) | more than 6 years ago | (#23931615)

I find a self-signed certificate is useful on many occasions. I use it for my own squirrelmail service. I have set them up for "extranet" applications for small business clients.

This is just fine. I give them a hard copy of the key signature and tell them to verify it before the accept it.

Someone above says the a CA adds nothing. I don't agree with that. They add identity verification *to the extent* that site visitors actually *read* the certificates and evaluate their level of trust in the CA.

Quick: Tell me right now how many CAs are in your browser's trusted certs list. Now tell me where that list came from. Tell me why you trust it.

In other words, the signed certificate system can provide excellent security, but most of us simply trust our browsers when they don't complain. That isn't security. You really should check certificates every time. View the details, check the signatures, verify the integrity of your trusted CA list. But who bothers?

So while I don't agree that CA signed certs "add nothing," I do agree that hardly any users (including me who theoretically knows better) do their due diligence that would make that system truly work.

As long as you trust the CA... (2, Insightful)

a302b (585285) | more than 6 years ago | (#23931661)

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.

Re:As long as you trust the CA... (0)

Anonymous Coward | more than 6 years ago | (#23931783)

Accepting a certificate ultimately comes down to trust. For example, most people trust Verisign.
Hmm... I wonder about that.. i think most people are *FORCED* to trust Verisign, as their root cert is included in the popular browsers, and they are oblivious to that it is even in there...

I dont remember ever making the choice if I trusted Verisign (or any other cert authority) for that matter.

Re:As long as you trust the CA... (1)

Znork (31774) | more than 6 years ago | (#23931953)

For example, most people trust Verisign.

They do? I certainly don't. Verisign has given me no reason to trust them, in fact, their corporate history, actions, statements as well as the judicial climate of their legal venue have given me plenty of reasons to explicitly distrust them.

The reason people trust sites like Verisign

I'd say the reason people trust Verisign is that it gets installed in their browsers by default and they cant be bothered to check. You could install RusChin Phishing Corporation as a default CA in peoples browsers and they'd trust that. So it comes down more to people trusting what their browser vendors put as default CA's. So do you trust Microsoft? Your Firefox distributor? Do you trust the judgement of someone who considers Verisign trustworthy?

Also, even if I trust a site, I wouldn't necessarily trust the people they trust.

Exactly. And the conclusion one can draw from that is that it's simply better to establish trust with each separate entity, or otherwise simply not trust them.

Firefox 3 (5, Informative)

Trogre (513942) | more than 6 years ago | (#23931675)

I've noticed that Firefox 3 is much less forgiving of self-signed certs than other browsers. There's a lot more hoops that one has to jump through to get a page to load.

I've found it rather annoying, since all our internal web applications are served via SSL.

Re:Firefox 3 (1)

fyoder (857358) | more than 6 years ago | (#23931723)

I've noticed that Firefox 3 is much less forgiving of self-signed certs than other browsers. There's a lot more hoops that one has to jump through to get a page to load.
Yup. It appears they're in competition with other browsers for who can create the greatest illusion of security. I think they may be winning.

Re:Firefox 3 (5, Informative)

Rovaani (20023) | more than 6 years ago | (#23931779)

Can't you just generate your own root certificate, use it to sign all the web-app certs and then distribute your own root certificate to all the employees?

Re:Firefox 3 (1)

Thiez (1281866) | more than 6 years ago | (#23932091)

Indeed you can. The distribution would be the important part. Emailing the root certificate to you employees would be stupid since email can be intercepted and changed (unless you sign it but you can't if the receiver doesn't have the certificate yet... a 'chicken or the egg' problem), so an attacker could insert his own certificate in the email and play man-in-the-middle between the company and the emloyee(s) in possesion of his certificate (for most businesses this scenario is relatively unlikely). Giving a very cheap memory-stick containing the certificate to every employee would work (if you trust the ones handing out the memory-sticks). In the end, it comes down to how paranoia you are :)

Re:Firefox 3 (2, Informative)

hrtserpent6 (806666) | more than 6 years ago | (#23931789)

Less forgiving? Maybe the first time.

All of our internal websites have self-signed certs. Once I added the permanent exception once, I never got another popup - unlike on FFX2 which gave me a box every time....

Re:Firefox 3 (2, Informative)

Thiez (1281866) | more than 6 years ago | (#23931921)

Why don't you add the root certificate to you browser? In Firefox 3: Tools -> Options -> Advanced -> Encryption -> View Certificates, then add the root certificate to your list of authorities. If memory serves me well, that should do the trick.

Depends on who your users are (1)

QuasiRob (134012) | more than 6 years ago | (#23931687)

If all you want to do is encrypt data then a self signed cert is fine, the trouble is the general public don't know this so when that pop-up appears in their browser they worry and you lose their trust.

As earlier posters have said, there is absolutely no reason to trust a commercial CA - you've never met them, you don't know who they are or what they are doing. The only reason to buy one of their certificates is because it keeps your customers happy.

An alternative, if it can get enough support? cacert.org

Re:Depends on who your users are (0)

Anonymous Coward | more than 6 years ago | (#23931855)

An alternative, if it can get enough support? cacert.org

MOD UP!

Seriously. Cacert seems to be the perfect solution. You get a central authority that verifies that you own the domain, yet it's still free.

The only thing missing is browser support. It seems to already be adopted in alot of distros according to this:
https://issues.foresightlinux.org/browse/FL-1458

When you do your own trust check (1)

Kjella (173770) | more than 6 years ago | (#23931703)

A SSL certificate, even if not from a trusted party has a stable fingerprint you can use to verify it. Hell, the threat of verifying the fingerprint it often enough. Like in this case, TPB don't need to be certified to any real person or organization. They just need to have the fingerprint published well enough people will agree this is the real Pirate Bay(tm) and not some MITM attack. And don't forget that SSL, unsigned or not protects against an attacker that can only read and not write data.

Honour Amongst Thieves? (0)

Anonymous Coward | more than 6 years ago | (#23931753)

So your concern is that you can't trust a self signed certificate from a pirate website?!?!? There's an interesting cognitive dissonance present in the very question...

They're technically correct, but.... (1)

jimicus (737525) | more than 6 years ago | (#23931769)

A self-signed certificate doesn't detract from the security, this is true. But a real certificate does place an (admittedly low) barrier to entry against fraudulent sites.

Windows has spent the last 15 years encouraging people to click away the dialogue box without reading it. Encouraging the use of self-signed certificates will lower this barrier to entry by encouraging people to think "ah, it's still secure so it's OK".

Re:They're technically correct, but.... (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#23931837)

Sorry, what steps does Windows take to "encourage" people to click away the dialog box without reading it?

People do it, but I didn't realize that was somehow Microsoft's fault. I must be new here.

What are you protecting ? (1)

AftanGustur (7715) | more than 6 years ago | (#23931797)

To answer your question about when a self-signed certificate is acceptable:
It depends on two factors:

1. What are you protecting
and
2. Against whoom.

When you know the answer to those two questions, you will know the answer to your initial question,

Depends what you're signing (1, Insightful)

Toreo asesino (951231) | more than 6 years ago | (#23931809)

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.

Key distribution (3, Informative)

c_g_hills (110430) | more than 6 years ago | (#23931859)

Using self-signed certificates inside an enterprise is fine so long as all the clients have the certificate authority's public certificate installed. Key distribution mechanisms like group policy make it simple.

Sadly Firefox makes it less secure because it uses its own key store rather than the host operating system's, so users must manually import the certificate before attempting to visit an SSL-secured website.

PirateBay? (0)

Anonymous Coward | more than 6 years ago | (#23931879)

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.

PirateBay, is that you?

In that case, I see no problem with a self signed cert, all you want is the encryption.

google adsense (0)

Anonymous Coward | more than 6 years ago | (#23931913)

It seems that the google adsense site also uses an unsigned certificate ...

Both ways are good (1)

salarelv (1314017) | more than 6 years ago | (#23931917)

In my opinion should browsers support self-signed certs by default because there are thousands of intranets for private use where there is no need for a CA certified cert. Like somebody said before secure web mail access is a important issue. For me is it important that the cert is coming from the same server where I'll try to log-in and nothing more. If the browser could detect that and only hint that this is not a CA certified cert - not to pop-up some warnings - would be just fine. I'll see also benefits for a CA certified certs. Like for pay-pal, banks, government sites I'll need certainty that the information I am currently posting isn't going to wrong hands.

What Are You Getting? (3, Insightful)

segedunum (883035) | more than 6 years ago | (#23931929)

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.

Re:What Are You Getting? (2, Informative)

rugger (61955) | more than 6 years ago | (#23932061)

You should get a proper certificate signed by a CA. With a proper certificate, the end user's web browser can verify that your certificate did actually come from your web server, and not some other random computer pretending to be your web server.

The reason why browsers complain about self-signed SSL certificates is not because they are self-signed, it is because they cannot be verified as coming from your web server. If you set up your own root certificate and install it into your user's web browsers, then it stops complaining.

If browsers stopped complaining about certificates they cannot verify, I'd definitely NEVER use the web for anything secure ever again.

Better than the alternative (1)

slim (1652) | more than 6 years ago | (#23931961)

The alternative to accepting individual certificates, is for 'Hypothetical Piracy Enablers' HPE to create their own CA, and for you to accept their CA certificate as a trusted signer.

There's nothing technically difficult about becoming a CA. OpenSSL can handle the bit-twiddling aspect with no problem. The hard bit about being a CA is all the authentication that's supposedly done before signing a certificate, and the risk and liability responsibilities taken on.

It sounds very convenient to accept HPE's CA certificate -- but wait -- that would mean that if some crook could persuade HPE to sign a certificate for (say) hsbc.com, your browser would accept it every time.

So, in this case, since you probably don't trust the signer all that much, it's better to accept the self-signed site certificate.

3 instances of when Self-Signed SSL is right (1)

bucktug (306690) | more than 6 years ago | (#23931991)

1. Test box
2. When you have a smaller user base of users that actually know you. Like a workgroup that might uses a web front end to a database that isn't usually public facing but for whatever business reason isn't behind a firewall.
3. When you are cheap.

Blah blah... price of everything... cost of nothing... blah blah...

*COUGH... (1)

jberryman (1175517) | more than 6 years ago | (#23931995)

*COUGHpiratebayCOUGH

Trouble is, SSL does two things and users are dumb (4, Insightful)

fuzzyfuzzyfungus (1223518) | more than 6 years ago | (#23932001)

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.

The question is about certificate validity (1)

Emperor Skull (680972) | more than 6 years ago | (#23932021)

The question about if a certificate is self-signed or signed by a CA isn't really the issue, it's ensuring that end-users don't get certificate warnings in their browsers. An end-user should NEVER have to click through a certificate warning. That means the name in the certificate has to match the site, the certificate hasn't expired, and the certificate is trusted by the clients browser. If your application is internal to your organziation then you can distribute the certificates. (For example, we distribute our self-signed root cert to Windows machines through group policy.) When you are dealing with the Internet and customers, then there is no excuse to have an invalid or untrusted certificate.

CACert.org (1)

Anonymous Coward | more than 6 years ago | (#23932115)

Personally, I use CAcert certificates for all my personal stuff. It's a bit easier than creating one's own CA or doing one-off self signed certs.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>