3 ms·

That's true, but "can I trust the party on the other end of this channel?" and "is the channel secure against third-party eavesdroppers?" are fundamentally two

• bombcar 5y ago
  HTTPS would have been a lot better (in my opinion) if it had been more like SSH when encountering a certificate it didn't recognize. Let's Encrypt finally solved that, but at the same time effectively made SSL certs mostly worthless for identity purposes (as it just means the domain you're talking to is the domain you're talking to).
  • josephcsible 5y ago
    Yeah, it's never made sense to me why browsers show such a scary warning before visiting a site over HTTPS with an invalid certificate, when they didn't show any warning at all before visiting a site over insecure HTTP, since the latter leaves you vulnerable to a superset of attacks.
    • tetraca 5y ago
      It makes sense though? If you're browsing via HTTP there is no expectation at all that what you are doing is secure. If you have a problem in HTTPS, you are expecting to be secure, you might not be. Hence, a warning.
    • andrewaylett 5y ago
      It's only recently that it's become reasonable to add interstitials without annoying everyone. Firefox in HTTPS-Only mode does exactly that. A bad certificate is a sign that something's actively wrong while (at least historically) no certificate doesn't really give a strong signal.
      • Karunamon 5y ago
        The problem is that those classes of wrongness are treated identically when they are emphatically not: scary, hard-to-understand-by-users warnings, if not outright inability to connect in some cases. A cert that's a day out of its expiration time has zero implications to the confidentiality and identity of the parties to the connection. The same cannot be said about a bad CN or signature.
    • snowwrestler 5y ago
      You’re right but it’s basically a cultural legacy. Most browsers really want to show scary warnings for HTTP connections these days. But there are enough complaints about it as a concept that they have not implemented it yet. “Zero trust” or “BeyondCorp” security strategies are not widely deployed; a lot of organizations still use browsers over HTTP for internal apps, and don’t have a captive CA or a way to satisfy Let’s Encrypt challenges from outside the firewall. No one wants thousands of companies to train their employees to ignore cert warnings. And there is a small but vocal set of folks who believe one should not have to satisfy a CA (even Let’s Encrypt) to put up a website.
      • jrockway 5y ago
        I don't think that broken corporate policies should dictate what the public web does. If they must use split-horizon DNS (which is the worst thing ever) and can't do a DNS challenge, there are still plenty of ways to make browsers avoid warnings; every IT department can push trusted certificates to workstations and mobile devices. It's built into every device management system in the world. If you don't manage employee devices AND can't get TLS certificates to internal applications, the employees are right to be scared by the browser's warning. You have failed as a corporate IT department.
    • NikolaNovak 5y ago
      I may be wrong, but it made sense to me: * Visiting site with HTTP, there's no expectation of encryption / comms security. So there's no need for warning. * Visiting site with HTTPS, there's expectation of encryption / comms security, so please let me know if it's not working as intended or there are warning signs. That being said, I'm at the crossroads of "little knowledge is a dangerous thing". Vast majority of my friends and family would not know HTTP is not encrypted... but they also won't even bother reading an experied cert warning and will just click to proceed. (on a broader level, working in operations has underlined to me that default user behaviour with any modal dialog, window, warning, error, is to click everything until something works. There is no reason whatsoever to read or understand WHAT was clicked, or pay it any attention later, other than remembering which thing was clicked. It's an entirely binary world of "things that when you click them don't make it work" and "things that when you click them make things work". There is literally no other useful information for most users)
      • lazide 5y ago
        Also, that most people will not remember what option they clicked as little as the instant they click it and the window goes away.
  • andrewaylett 5y ago
    If you thought things were better before LetsEncrypt, I'm afraid you were mistaken. They weren't the first to provide free DV certificates, and even paid certificates aren't immune to crises of identity. Troy mentions the EV certificate issued to "Stripe, Inc" which caused so much consternation back in the day. Not to mention that it's never been difficult to get a certificate for a dodgy domain, especially when doing so made a phish more likely to succeed.
  • Gormo 5y ago
    > Let's Encrypt finally solved that, but at the same time effectively made SSL certs mostly worthless for identity purposes Which was and is reasonable, given that encryption mitigates risks that can't be mitigated otherwise, and is therefore a more pressing concern for security -- you can take many other measures to verify who the party on the other end of a connection is, but once unencrypted traffic exits your network, there's not much you can do to prevent snooping. It again goes back to muddling up these two separate concerns. If we used CA-issued certificates only for identity validation, we could have optimized them for that purpose and not diminished their value because the need for ubiquitous encryption was a higher priority. Meanwhile, we could have just had web servers auto-generating encryption keys (a la SSH, as you point out), without being shackled to the trust hierarchy, and had universal adoption of HTTPS 20 years ago. Instead, we got a single solution to two different problems that is still forcing us to compromise one for the other.