Forgot your password?
typodupeerror
Encryption Security

When Is a Self-Signed SSL Certificate Acceptable? 627

Posted by kdawson
from the how-about-never-is-never-good-for-you dept.
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?"
This discussion has been archived. No new comments can be posted.

When Is a Self-Signed SSL Certificate Acceptable?

Comments Filter:
  • Always. (Score:5, Informative)

    by fyngyrz (762201) * on Wednesday June 25, 2008 @05:53AM (#23931473) Homepage Journal

    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.

    • Re:Always. (Score:5, Insightful)

      by jamesh (87723) on Wednesday June 25, 2008 @06:03AM (#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.

      • Re:Always. (Score:4, Interesting)

        by chowells (166602) on Wednesday June 25, 2008 @06:37AM (#23931793) Homepage

        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)

          by bpkiwi (1190575) on Wednesday June 25, 2008 @06:59AM (#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.
        • by jamesh (87723)

          Not very easily, but you can use two factor authentication to make sure that even if scammers find out the static username, password

          I've got one of these for my banking, and have had it for a few years now. I've also implemented rsa tags on a clients terminal server. And yes, they do solve a lot of problem, especially clients being less then perfect with their password complexity.
        • Re:Always. (Score:4, Insightful)

          by Nursie (632944) on Wednesday June 25, 2008 @07:39AM (#23932239)

          But there you're solving a completely different problem!

          The SSL certificate scheme is there to assure your browser (you) that the bank is who they say they are.

          The electronic pad and/or card are there to assure the bank that you are who you say you are.

          Completely different problems. Without the first being solved (usually via SSL) then you have no idea who you're giving your username, password and one-time number to.

          IMHO this is a MAJOR problem in security. Most people don't understand that there are multiple different issues of trust, secrecy and integrity to be solved in any given situation.

      • Re:Always. (Score:5, Informative)

        by the_womble (580291) on Wednesday June 25, 2008 @06:52AM (#23931905) Homepage Journal
        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. (Score:5, Interesting)

          by jamesh (87723) on Wednesday June 25, 2008 @07:35AM (#23932221)

          1) SSL certificates do get issued to phishing sites

          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.

          2) Some banks have login forms on un-encrypted pages

          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.

          • Just because the form PAGE is not HTTPS doesn't mean the form PUT isn't HTTPS, i.e. a form that doesn't show the little lock icon might still be perfectly secure, but without looking at the page source you won't know about it.

            And, ironically, vice versa. I.e. you can have a HTTPS form that actually uses unencrypted HTTP to submit its' data. Your browser is supposed to warn you when you submit an HTTP ("insecure") form and when you go from HTTPS to HTTP within the same site, but after the first couple of tim

        • by Burz (138833) on Wednesday June 25, 2008 @07:47AM (#23932303) Journal

          However, that is why Https security has to stand on a 'tripod' from the users' point of view:

          1) The lock icon appears in the address bar (while a picture of a lock on the page doesn't count).

          2) The domain name in the address bar is spelled correctly (because the lock is saying that the cert 'matches' the domain).

          3) No certificate warnings appear from your browser.

          If any one of those 'legs' is missing, then assurance of link security falls down. Otherwise (barring your computer being infected/compromised, or having a massive bug) you can be sure the link is both solid and also not a phishing site.

      • Re:Always. (Score:5, Informative)

        by hal9000(jr) (316943) on Wednesday June 25, 2008 @09:05AM (#23933189)

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

        Yes. Back in 2001, Verisign issued 3 code signing certificates [com.com] to people impersonating Microsoft employees.

        As others I am sure have already said, the strength of the identity verification is solely based on how the verification is done.
    • Re:Always. (Score:5, Insightful)

      by jolyonr (560227) on Wednesday June 25, 2008 @06:06AM (#23931559) Homepage

      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

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

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

        • This is slashdot anything dealing with spending money and a company making profit is bad. Yet they will complain that their salaries are too low, and have hard time finding job.

        • Re:Always. (Score:4, Informative)

          by Tony Hoyle (11698) <tmh@nodomain.org> on Wednesday June 25, 2008 @08:25AM (#23932709) Homepage

          No they don't. We have a code signing cert. I got it by email - I'm not the owner of the company or anything.. I just looked up the company reg. number and sent them the registered address and they replied with the link to the certificate the same day.

          I could have been *anyone* - there was absolutely no real verification.. I literally googled all the information as it was quicker than asking my boss. For this they wanted $200.

      • Basicly, if you trust the included root certs, then you basicly trust that some person who installed the certificate on the site at one point had access to an e-mail address on the domain, or something like that. It guarantees nothing.

        Self-signed certificates lets the user decide if he want to trust the site, and the user should be given a warning when the certificate changes, i.e. man-in-the-middle.

        I would say self-signed are better. But they MUST match the domain name.

    • Re:Always. (Score:4, Interesting)

      by Yvanhoe (564877) on Wednesday June 25, 2008 @06:19AM (#23931665) Journal
      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. (Score:5, Informative)

      by squiggleslash (241428) on Wednesday June 25, 2008 @06:27AM (#23931725) Homepage Journal

      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.

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

    • Depends. (Score:2, Informative)

      by Anonymous Coward

      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 a

    • 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

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

    • 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,

    • by Burz (138833)

      He is spreading misinformation. The Internet and its security mechanisms were never meant to verify real-world identity (whatever that means: photo, street address, SSN?) or good intentions. Yet SSL does, however, validate the site's Internet identity... it ensures that the domain name you see in your address bar represents the actual server(s) registered to that domain name. As others here already pointed out, this prevents MITM attacks.

      Thus, when you conduct critical business on the Internet, it is import

      • Re: (Score:3, Interesting)

        by sjames (1099)

        it ensures that the domain name you see in your address bar represents the actual server(s) registered to that domain name. As others here already pointed out, this prevents MITM attacks.

        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.

  • Interesting (Score:2, Interesting)

    by Mensa Babe (675349) *

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

    • Re:Interesting (Score:5, Insightful)

      by locofungus (179280) on Wednesday June 25, 2008 @06:21AM (#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 (Score:5, Insightful)

      by Znork (31774) on Wednesday June 25, 2008 @06:34AM (#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.

    • by wrook (134116)

      "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

      • by tepples (727027)

        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.

    • by dave420 (699308)
      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.
    • by kestasjk (933987)

      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,

    • by mystik (38627)

      "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, ev

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

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

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

  • by OeLeWaPpErKe (412765) on Wednesday June 25, 2008 @06:07AM (#23931571) Homepage

    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.

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

  • by JenniP (824070)

    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

  • by Chrisq (894406) on Wednesday June 25, 2008 @06:10AM (#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: (Score:2, Informative)

      by wtanaka (13113)

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

    • by asc99c (938635)

      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.
      • by tepples (727027)

        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.
        Public key crypto verifies that the party you're communicating with now is the same party you communicated with before. Verifying that the party you're communicating with for the first time is the same party who owns a given domain is a separate task, and SSL conflates the two tasks.
  • by locofungus (179280) on Wednesday June 25, 2008 @06:10AM (#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.

  • Tons of them (Score:5, Informative)

    by evilpenguin (18720) on Wednesday June 25, 2008 @06:12AM (#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.

  • 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 legitima
    • by Znork (31774)

      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 def

    • by tepples (727027)

      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).
      Would you trust a bank's self-signed certificate if you can ask an account rep at any branch for the fingerprint on a business card?
  • Firefox 3 (Score:5, Informative)

    by Trogre (513942) on Wednesday June 25, 2008 @06:19AM (#23931675) Homepage

    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 (Score:5, Informative)

      by Rovaani (20023) on Wednesday June 25, 2008 @06:34AM (#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: (Score:2, Informative)

      by hrtserpent6 (806666)
      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: (Score:2, Informative)

      by Thiez (1281866)

      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.

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

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

  • 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,

  • 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 (Score:4, Informative)

    by c_g_hills (110430) <chaz@ch[ ].com ['az6' in gap]> on Wednesday June 25, 2008 @06:45AM (#23931859) Homepage Journal

    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.

  • by segedunum (883035) on Wednesday June 25, 2008 @06:57AM (#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: (Score:3, Informative)

      by rugger (61955)

      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

    • Re: (Score:3, Insightful)

      by Deadplant (212273)

      Using certificates is about one thing - encrypted communication between browser A and server B. That's it.

      That is not correct.

      Certificates have never given you any guarantee as to the integrity of the site

      Correct.

      it gives no guarantee whatsoever of who you are talking to, as some people are stupidly claiming around here.

      Actually, that is the ONLY reason certificates exist.
      You do not need a certificate to encrypt communication.
      Certificates are an identity authentication tool.

      Obviously it cannot ensure that it is Fred on the other end of the line. It only ensures that it is a computer with Fred's key. It is up to Fred to keep people from stealing his key and impersonating him.

      If you are considering using SSL on your new website I suggest you go and read up on it.

    • Re: (Score:3, Insightful)

      Using certificates is about one thing - encrypted communication between browser A and server B. That's it. [...]it gives no guarantee whatsoever of who you are talking to

      No they aren't. Also, there is no point in encrypting between A and B if A and B have no idea who each other are. A or B could in fact be one of the very people you're using encryption to protect your communications from. You have no idea.

  • 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 ce

  • by fuzzyfuzzyfungus (1223518) on Wednesday June 25, 2008 @07:08AM (#23932001) Journal
    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.
  • If a large number of people complain that a company is not who it claims to be or a certificate is compromised the CA can potentially blacklist the certificate.

    I guess this is a potential advantage of a CA, even though they are generally pretty useless.

  • Signed certificates provide exactly one additional protection versus no certificate at all: sessions so protected are not vulnerable to a man in the middle attack. With a self-signed certificate, someone in the middle can create a new self-signed certificate, decrypt and log your communications and then re-encrypt them with the site's real certificate. As the user, you won't know because it all looks the same to you.

    That having been said, SSL with a self-signed certificate is MUCH more secure than no encryp

  • True Story (Score:5, Interesting)

    by BLKMGK (34057) <morejunk4me&hotmail,com> on Wednesday June 25, 2008 @07:31AM (#23932197) Homepage Journal

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

  • by hal9000(jr) (316943) on Wednesday June 25, 2008 @09:10AM (#23933269)
    The answer to you question is that you can use a self-signed certificate anywhere you can use one signed by a CA, public or not. However, to ensure that you are always talking to the web server and not through a MITM, you must distribute the self-signed certificate or the certificate thumbprint (and then verify it!) through some trusted means.

    Using a public CA like Verisign buys you is that since their public CA certificates are already distributed in browsers, any certificate issued by them should just work. Oh, and make sure the host name matches the common name.
  • by OldHawk777 (19923) * <oh21@@@comcast...net> on Wednesday June 25, 2008 @12:33PM (#23936635) Journal

    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)

    by psydeshow (154300) on Wednesday June 25, 2008 @02:26PM (#23938383) Homepage

    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.

"Look! There! Evil!.. pure and simple, total evil from the Eighth Dimension!" -- Buckaroo Banzai

Working...