3 ms·

This is probably a step forward for HTTPS, but it still bugs me that most of the internet is running on a cryptography system that doesn't provide confidentiali

• mcpherrinm 3y ago
  I'm biased, of course, because I work for Let's Encrypt, and spend a lot of time thinking about the trade-offs and how to make this ecosystem better. I think claiming that "SSH provides stronger security guarantees than X.509 certificates" is pretty outlandish. SSH is trust-on-first-use. How many people actually verify the key fingerprints? Maybe you do when you're sshing to your single corporate bastion, or to Github.com, but could you imagine if you had to do that for every website? It simply would not work. It only barely does for SSH because of the (relatively) low amount of use SSH gets. When at a previous company I set up an SSH CA, we found an SSH MITM within 3 days (though benign; an ISP-provided modem/router was resolving all hostnames to itself when the WAN was down), and the user was planning on just accepting the new SSH host key. Certificate Transparency is an auditing system, so of course it's after-the-fact. It has helped to improve the CA system immensely. While there's still work to do, the TLS ecosystem is unrivalled in terms of actual security benefit delivered to the most people.
  • hedora 3y ago
    With SSH, if you care, you just need to check the fingerprints. With HTTPS, you have to implement certificate pinning (or set up a private CA and configure everything to ignore the system roots of trust), which is much more onerous. Thanks for helping to improve https, since it helps in practice. edit: Another way to put it is that if you want to reduce your attack surface to just the client and server machine, it's easy enough to scale SSH fingerprint verification to a few dozen machines. It's much, much harder to get SSL to provide that property for even two machines. As for scaling to 100's of machines, it's not obvious to me that bootstrapping and rsyncing a known_hosts file and /etc/ssh_config that turns off trust on first use is harder than setting up a CA. For millions of machines, SSH falls over (because known_hosts would be too big), but at that point, you're talking about what percentage of machines are compromised in steady state, not how to keep all attackers out. That's where HTTPS works well.
  • kfreds 3y ago
    > While there's still work to do, the TLS ecosystem is unrivalled in terms of actual security benefit delivered to the most people. Well said!
  • jancsika 3y ago
    > When at a previous company I set up an SSH CA, we found an SSH MITM within 3 days (though benign; an ISP-provided modem/router was resolving all hostnames to itself when the WAN was down), and the user was planning on just accepting the new SSH host key. Wouldn't that be a problem with TOAU? :)
    • mcpherrinm 3y ago
      Sorry, I'm having trouble understanding that acronym. What do you mean? In this case it was a TOFU error, as somebody was trying to SSH to a new AWS instance, so they'd have trusted the certificate "on first use", even though they were actually SSHing into their network's router.
• MattJ100 3y ago
  It probably won't happen, but I'd love to see the concept of channel binding reach the web ecosystem. It allows you to securely verify the certificate, independent of any third party. However it only works when you and the server have a shared secret (which could be a password or something else). It therefore isn't really applicable to casual "anonymous" browsing. But for that kind of browsing, a third-party attestation (e.g. from a CA) is probably good enough anyway. We use channel binding in the XMPP ecosystem and it's going well.
• zozbot234 3y ago
  If you're ok with TOFU ala ssh you can just use self-signed certificates. Skipping the browser warning is the "trust" equivalent.