4 ms·

Off-topic, but does anyone know why browsers go crazy about self signed certs? It's not as good as one signed by an ostensibly trusted CA, but it's strictly be

• wazoox 15y ago
  It's explained on the Wikipedia entry : http://en.wikipedia.org/wiki/Self-signed_certificate http://en.wikipedia.org/wiki/Self-signed_certificate Basically, self-signed certificates can't be revoked in case of a security breach. There's an excellent resume of the discussion of the subject at Mozilla : http://www.gerv.net/security/self-signed-certs/ http://www.gerv.net/security/self-signed-certs/
  • smanek 15y ago
    Any attack I can think of that exploits that fact would work at least as easily on plain HTTP. And there are a large class of attacks that work on plain HTTP but not with a self signed cert. Can you think of any counter examples? (Note: I'm a security noob - so I'm asking out of sincere curiosity).
    • wladimir 15y ago
      I don't think there is any doubt that even with a self-signed certificate, HTTPS is more secure than HTTP. At the least, it makes interception/sniffing/modification a bit harder. Security, after all, is about making attacks more difficult and costly. Still there is good reason that browsers rub it in the users face when a site tries to use a self-signed certificate. The user has to be really really sure that this is expected (it is like the SSH "the remote host key has changed" warnings).
      • smanek 15y ago
        Maybe I'm missing your answer there ... You just say: Still there is good reason that browsers rub it in the users face when a site tries to use a self-signed certificate but I don't see where you say what that good reason is. If a self-signed cert is more secure than plain HTTP, why make a self-signed cert more painful to use than plain HTTP?
        • wladimir 15y ago
          Because with HTTP, there is no assumption of security at the side of the user, or at least there shouldn't be. With HTTPS (and the "lock symbol") there is. The people that really know what they're doing can click through the warnings and still do what they want. But casual users that assume https=safe have the chance to leave. I'm all for deprecating HTTP the same way they did with TELNET, and warning the user for every HTTP site they go to, but that's a wholly different discussion :)
          • goldmab 15y ago
            The browser could just not show the "secure" visuals, instead of making us click through another page.
            • wladimir 15y ago
              Well, the warnings are only shown once. Once you import the self-signed certificate into your keystore, it never bothers you again (unless the certificate changes). This is the right workflow you should follow with self-signed certificates, it is similar to SSH. You need to accept the certificate once. After manually verifying it is the right one, you're even more secure than trusting on a CA...
              • goldmab 15y ago
                It's a usability problem. Firefox (at least 3.x) does a full-on freak-out if the cert is untrusted, despite the fact that the site is no more unsafe than an unencrypted website. Your statements about what should happen are only true if you are requiring encryption for everything that you do. On the web, it's assumed (although most people don't actually know this) that your information is not secure unless you see the green bar or whatever the security visual is on your particular browser. This brings me back to smanek's point. We have three levels of security: no SSL, untrusted cert, trusted cert. Nothing about the first level is superior to the second level, except for the possibility of a false sense of security. Therefore, a browser should not freak out more in the second situation.
• pmjordan 15y ago
  Self-signed certificates don't prevent MITM attacks on connecting unless you've transmitted the certificate securely out-of-band and installed it in the client's browser. (which practically never happens with sites on the open internet) They only prevent tampering with the connection once it's established. The browser should jump up and down when encountering such a certificate as it's exactly how an attempted MITM attack would look.
  • smanek 15y ago
    Granted, it doesn't provide as much protection as a cert signed by a trusted CA - but it's still far more protection than plain HTTP, right? e.g, Firesheep wouldn't work I don't know if browsers do this, but in principle they could even notify the user on certificate change, so the MITM would have to be on the first connection to a site.
    • jrockway 15y ago
      Firesheep would work. The attack is more involved than just openly sniffing packets. You need to poison the DNS cache on the victim's machine, so that facebook.com resolves to you. Or, you need to poison the ARP cache, so the victim machine thinks that you are the router. These are both easy to do, though, and once you've done that, then you are a man that's in the middle, and MITM attacks are easy under those circumstances. "ettercap" is a program to automate this technique to spy on SSH, HTTPS, etc. Works quite well.
      • deleted 15y ago
        [deleted]
    • vladd 15y ago
      Introducing a "third state" for the SSL indicator, usability-wise, is very difficult. A lot of browser users don't understand SSL, and those that do have a binary understanding of the protocol: it can be used to either confirm or refute the identity of a website. It's very difficult to implement a UI for the regular users that says: "this might be a MITM attack since I cannot confirm the identity of the site but at least I can confirm that it's the same with the one that you connected with the first time".
• codeup 15y ago
  The CA system is broken and browser vendors try to deal with it. Deal with it = trade off between security and (in)convenience.