

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

I&#x27;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).<p>But isn&#x27;t that better than nothing? Even if my blog has a self-signed certificate and you can&#x27;t say for sure that &#x27;this blog is run by so-and-so&#x27;, isn&#x27;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.<p>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 &#x27;strict mode&#x27; enforcing the current behaviour (require authentication) for environments or users which prefer it.<p>The major problem I see here is that sites where you <i>do</i> 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&#x27;m not sure if there are tangible ways around that, but it feels worth looking into.
======
Someone1234
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.

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

~~~
Someone1234
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)?

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

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

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

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

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

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

(I'm in that group)

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

