Ask HN: Aren't self-signed certificates preferable to unencrypted connections? | Hacker News Reader

Ask HN: Aren't self-signed certificates preferable to unencrypted connections?

3 pointsdanudey12 comments

I've had all kinds of issues in the past (as a sysadmin) testing systems with self-signed certificates (before we have real certificates issued). For example, testing a new mail server, a client website, etc. Most systems will show an alert, and many just refuse to work entirely (e.g. SMTP relaying) without a significant amount of configuration change (which then has to be undone later).

But isn't that better than nothing? Even if my blog has a self-signed certificate and you can't say for sure that 'this blog is run by so-and-so', isn't that better than a wholly unencrypted connection? SSL seems to be used for two purposes, namely encrypted connections and validating the remote server, but surely encrypted connections alone are a sufficient benefit? And yet, if all I want to do is have a secure channel, I have to (theoretically) pay a certificate issuer yearly to prove that I am who I am, as if encryption requires I prove my identity.

It would make a great deal more sense to me to treat self-signed certificates the same way we treat HTTP sites: give no notification to the user whatsoever, unless they go looking for it. Browsers could also have a 'strict mode' enforcing the current behaviour (require authentication) for environments or users which prefer it.

The major problem I see here is that sites where you do want to guarantee certificates (e.g. Facebook.com, google.com, bank of america, etc) would be difficult to guarantee that you were connecting to the correct site, since MITM attacks against your SSL connection would be treated like HTTP connections and the browser would let them proceed as if nothing was wrong. I'm not sure if there are tangible ways around that, but it feels worth looking into.

Self-signed and no encryption are one in the same.

If an attacker is in a position to read unencrypted traffic, they MIGHT be in a position to inject DNS responses, or otherwise intercept traffic. If they can do that, they can generate a new self-signed certificate, MITM, which effectively disabled encryption (without making the user aware).

I will say, I feel like it is "unfair" that browsers give you an error page for self-signed but don't for regular HTTP. Why not just show a self-signed HTTPS page identically to how you would show a HTTP page (insecure, no padlock, etc). Also do mixed content warnings as if self-signed is insecure/HTTP.

An alternative which exists, which a lot of people ignore, is instead of doing self-signed generate your own CA and then sign your own certificate. You can install the CA in the root CA store on the OS and then you won't be using a "self-signed" certificate, you will be using a fully signed certificate with all of the security that that comes with (assuming you keep your root CA offline/safe).

PS - It took me many years to come to the realisation that self-signed encryption is effectively no encryption. You just really have to come at it from the "Starbucks insecure WiFi" perspective. Once you think of it like that, self-signed is too trivial to MITM and thus the encryption can be undetectably circumvented.

A regular HTTP connection declares itself to be insecure, and is.

A self-signed HTTPS connection declares itself to be somehow secure, but demonstrably isn't.

Neither declares themselves as anything. They're just exposed interfaces. The browser is the one making declarations about a connection's security.

So why not declare both equally insecure (which is true)?

That's just not true. Internet users are trained to look for HTTPS security indicators. Nobody is trained to distinguish between "marginally improved security" and "actually improved security". But in the former (self-signed) case, nobody, for instance, should be providing credit cards.

Your first and second sentences contradict one another.

You say it is "just not true" (that browsers declare them secure/insecure) and then go on to say "users are trained to look for HTTP security indicators" (exposed by the browsers).

So I'm quite confused about what it is you think I said which is "not true." Since you obviously do agree that browsers declare things secure or not.

Your example about credit cards is entirely non sequitur. It doesn't follow what you said before nor make sense in the context.

I can only suspect you misread something earlier in this conversation as your replies are quite confusing.

HTTPS security indicators. An indication that they are on a secure HTTP connection.

We really need an alternative. Somehow we need to make sure that all communications are encrypted. I understand that there needs to be a cost to prove your identity, since the CA needs to invest time in validating the identity of the person or organisation applying.

We have a situation currently where encrypted transport is tied to an SSL cert, which in nearly all cases is tied to a cost (because of the CA identity issue). Therefore SSL isn't prevalent enough.

I'd like to have SSL on my personal blog and my webmail, but I don't want to pay for a couple of hundred dollars for a wildcard subdomain cert that lasts one year.

The NSA stuff shows that we need to switch to a secure transport. It's the only way to hinder the dragnetting.

The problem I see is a false sense of security: Users will just see a lock in their address bar and think they're safe -- even if they're on a phishing site with a self-signed certificate.

It appears that users have been conditioned to look out for at least that little lock symbol, so devaluing it now would throw a lot of user training down the drain and give phishers fresh wind.

I think we could get some kind of intermediate state though - Red is the expired/invalid cert, yellow could be valid self-signed (where you don't trust the issuer), and green is fully validated trust.

Why not then just treat the page like it's unencrypted? For the users trained to look for the lock icon, they could look up to the bar and see it marked like an unencrypted page.

I've just seen the false sense of security argument backfire. I remember a sysadmin performing a "security upgrade" by converting a self-signed HTTPS server into an unencrypted HTTP server. The users were quite happy that their data was far more secure than it was under the old regime with the scary warnings, despite the fact that they were now being sent completely in the clear.

What about users who aren't trained to look for the lock icon, but rather for the https?

(I'm in that group)

They keynote at shmoocon this year actually asked browser vendor's to trust self-signed certificates more then standard HTTP connections.

Reply on news.ycombinator.com