Hacker News Reader

Comment by revelation | Hacker News Reader

I never thought about it from that angle. You are right, it makes no sense for browser vendors to display a big fat warning page because someone signed a certificate himself while they never let you know that 90% of the websites you use are transferred in plain-text over a wholly untrusted network.

View on HN

Again: that big fat red warning is the only thing that happens when an attacker hijacks the DNS for Citibank.com at your ISP, redirects traffic to herself, and intercepts all the TLS online banking warnings. Without the big red warning, you might as well not have certificates at all, because nobody would ever notice MITM attacks on TLS. None of the cryptography in TLS works unless users can be assured that every single HTTPS request will generate a big red warning box if the certs don't check out.

I absolutely understand how confounding the self-signed certificate warning seems when viewed solely in the context of normal sites operating under normal conditions. But that warning box doesn't mean "this site could be a whole lot safer if it was just configured better!" It means what it says: "you are probably under active attack".

Yes, there's a Bayesian problem here: most of the time, you are not actually under attack, and the site operator is in fact just using a poor configuration. But the browser can't know that; it has to assume you're under attack, because there's no other signal available to it to determine otherwise.

Yeah, except, since as you say, "most of the time, you are not actually under attack", that's exactly what end-users think, and learn to ignore the warning regardless. So, while you may save some tech-savvy users, all your normal users will just click through. I've seen this happen first hand on multiple college campuses with dozens of users where I've been the IT Support/Network Admin. Too many false positives and you end up with security theatre instead of actual protection.

Which is why the warnings are getting steadily more annoying.

What's the alternative? There is no difference on the wire between a self-signed certificate for a site that simply doesn't care about certificates, and a self-signed certificate that is the sole marker of an attacker having hijacked the TLS connection of a site that very much does care about its security. A MITM attack looks identical on the wire to a self-signed cert.

So instead of telling people "you're safe unless Joey cries wolf", tell people "you're safe if Joey says there are no wolves".

I don't understand this comment so I'll just repeat: a TLS connection that uses a self-signed certificate by design and a MITM attack against a site look identical on the wire.

So do an unencrypted normal site and an unencrypted attack site (like my spam folder is full of links to).

Most self-signed sites are fine, but because a few are MITM attacks, they should all throw big warnings (which users will learn to ignore, because of poor signal-to-noise).

Most unencrypted sites are fine, but because a few are attack sites, ....

The criteria for a user to enter sensitive info should not be "the connection is encrypted" or even "the connection is encrypted and goes to the server it says it does", but "I know the real-world identity of who I'm talking to".

The criteria to warn the user against entering sensitive info should be the negation of that; "I don't know the real-world identity of who I'm talking to".

The means of warning the user, should be such that the user does not need to act when not trying to enter sensitive info. So rather than pop-ups or interstitials that have to be dismissed -- and that the user can learn to dismiss -- there should be some persistent UI cue (like the green "Citigroup Inc (US)" beside the address bar) that the user can check when needed.

    Browser: "Bad cert! The world's gonna end!"
    User: "That's just a discussion forum, I don't care."
    Browser: "Bad cert! The world's gonna end!"
    User: "That's Joe's blog, I don't care."
    Browser: "Bad cert! The world's gonna end!"
    User: "yeah yeah, that's nice"
    Browser: "Bad cert! The world's gonna end!"
    User: "Would you shut up already!"
    User: "...Why is my bank account empty!?"

I don't understand why you keep saying "attack site". The problem the self-signed cert warning addresses isn't malicious sites; it's attackers who intercept TLS connections to online banks and swap out the Verisign certificate with a self-signed certificate.

The warning isn't about the site; it's about the connection.

The warning isn't about the site; it's about the connection.

Yes. Which is a bad idea. It conflates an absence of network shenanigans with "the user knows who he's talking to".

I'm really having trouble following your argument here. The only reason the user wouldn't know who he's talking to is shenanigans. You're complaining about the shenanigans alert.

  > it's attackers who intercept TLS connections to online 
  > banks and swap out the Verisign certificate with a self-
  > signed certificate

How is a MITM attack with a self-signed certificate any different than redirecting a user to a HTTP site instead of an HTTPS site? Do you really think that 'Joe Sixpack' knows the difference between http and https the way that you do?

You're saying that users can distinguish between the following possibilities:

- A site is over http, so it's insecure (and no big red warning).

- A site is over possibly compromised https with a big red warning, so it's insecure.

- A site is over verified https with a big green "everything is ok" light, so it's secure.

You seem to think that the average user knows that HTTPS needs a "red light/green light" system, but HTTP does not (because it's inherently insecure). I posit that the average user doesn't 'get' the difference between http with no warning and https with a green light. Why not have a system that is simple for the end-user? E.g.:

  - green light == secure
  - no green light == insecure
  - no need to differentiate between http/https for
    the average end-user

The suggestion is to tell people "you are safe if there is a green padlock in the address bar", and only display the padlock if the certificate is signed by a trusted authority.

Again, apart from the fact that the absence of a green padlock is an insufficient alarm for "your site is being hijacked by a MITM attacker", a session with a web application consists of many hundreds of individual connections.

"What's the alternative? There is no difference on the wire between a self-signed certificate for a site that simply doesn't care about certificates, and a self-signed certificate that is the sole marker of an attacker having hijacked the TLS connection of a site that very much does care about its security. A MITM attack looks identical on the wire to a self-signed cert."

How about adding another signal? It sounds like you're arguing with the sea, expecting normals to change.

Use the recent https-only header that says "if you ever see an insecure connection to this site, it's a bug", and pre-populate the list.

Stop assuming that users will eventually get it, and design a better product.

How does HSTS (the "https-only header") help with self-signed certificates? HSTS doesn't mean "this site won't work if its certificate is self-signed".

Does the HSTS list store the signature? Seems like if you see an HSTS site later convert to self-signed, that's always a security breach.

> Does the HSTS list store the signature?

It doesn't matter. The ONLY thing HSTS does is tell the browser to make future requests over HTTPS. If an HSTS site switches to a self-signed cert between my visits, the browser will still get warn me, because the new cert is suspicious.

Yes. Of course we still need the certificate system and the big fat warning boxes.

But you didn't address the problem here. You are essentially arguing we should keep the steel-bolted doors, and I agree, but that doesn't exclude us from doing something about all the traffic that doesn't even have padlocks.

HN doesn't promise me encrypted access to content, so I do not care whether it's encrypted or not. HN is not an online bank.

My bank however obviously must promise me encrypted access, or else nobody would use it.

The browser has no way of knowing whether a site should be encrypted; only that is says it is encrypted.

>My bank however obviously must promise me encrypted access, or else nobody would use it.

Hahaha, you're joking, right?

The core issue is that encryption is useless without authentication. A MITM could just replace the original self-signed certificate with his own and read the decrypted plaintext while proxying the request so the user doesn't notice.

Yes; more importantly, a MITM can replace a validly signed certificate with a self-signed certificate. If browsers are lax about self-signed certificates, all TLS connections are weakened, not just the ones that "opt out" of "good" certificates.

Not exactly. The fat warning is there so that you don't get a false sense of security by seeing a little lock.

But then again, we're now moving to a "if its self signed, you can't access the site, you can't bypass the check even".

I wonder how much verisign pays some of us.

Verisign did not pay Mozilla to make it harder to click through the broken certificate warning.

Do you mean that you can't bypass the certificate warning anymore in Firefox? (or will not in the near future)

If that is so, what is your reasoning behind it?

we're now moving to a "if its self signed, you can't access the site, you can't bypass the check even".

wait wait wait what?

I am currently in a space where we have to deal with self-signed certificates all the time. I fully accept that people like me will have to deal with more hassles from this so that people don't get their paypal accounts hijacked as easily. But I've yet to find out that I simply cannot connect to a site with a self-signed certificate.

Have a look at http://www.imperialviolet.org/2012/07/19/hope9talk.html for a glimpse of the future:)

Reply on news.ycombinator.com