3 ms·

> Not this time. The technical problems are easy to solve. For decades, users of SSH have had a system (save the certificate permanently the first time you conn

> Not this time. The technical problems are easy to solve. For decades, users of SSH have had a system (save the certificate permanently the first time you connect, and warn if it ever changes) that is optimal in a sense: it works at least as well as any other solution. It's trivial to implement, is completely free, involves no third parties, and lasts forever. To the surprise of absolutely no one, web browsers don't support it. This is completely backwards: TOFU schemes aren't acceptable for the public web because the average user (1) isn't equipped to compare certificate fingerprints for their bank, and (2) shouldn't be exposed to any MITM risk because they forget to. The entire point of a public key infrastructure like the Web PKI is to ensure that technical and non-technical people alike get transport security. (The author appears to unwittingly concede this point with the SSH comparison -- asking my grandparents to learn SSH's host pinning behavior to manage their bank accounts would be elder abuse. It works great for nerds, and terribly for everyone else.)

ericbarrett 1y ago
Does it even work great for nerds? I have seen a distressing amount of turning host key warnings off, or ignoring the warnings forever, or replacing a host key without any curiosity or investigation. Seems even worse in the cloud, where systems change a lot.
- woodruffw 1y ago
  > Does it even work great for nerds? No, but I was extending a charitable amount of credulousness :-)
- Spivak 1y ago
  I think it's pretty reasonable to turn off the "yes i would like to accept this key" on first connect. Just scream if it ever changes. I get that they're expecting me to compare it to something out of band but nobody does that.
  - blenderob 1y ago
    > I think it's pretty reasonable to turn off the "yes i would like to accept this key" on first connect. Why is it reasonable to trust the key on first use? What if the first use itself has a man-in-the-middle that presents you the middle-man's key? Why should I trust it on first use? How do I tell if the key belongs to the real website or to a middle-man website?
    - 1718627440 1y ago
      What is the "real website"? You do not know this in the general case, it is just some rando on the internet, which is indistinguishable from a middle-man.
      - Ferret7446 1y ago
        It is whoever owns the domain. The point is when your client talks to a domain, you know you are actually getting the domain, even if you don't know who owns it or if they're trustworthy. It removes an unnecessary variable.
        1718627440 1y ago
        Domain ownership is declared by someone randomly answering to a DNS request. If someone else answers, than what does it mean to "own a domain".
        blenderob 1y ago
        Not at all. I might have my own DNS server to answer my DNS request or I may trust a specific DNS server (not controlled by my ISP). My DNS entry may be 100% correct and resolving to my actual bank website. But with TOFU, on first use, it is still possible for a router/ISP/middle-man in between to intercept the response being served from the real website and serve a MITM certificate to me.
        1y ago
- evilduck 1y ago
  Even amongst nerds I've seen a significant amount of key pair re-use in my time, both 1:n::dev:servers and sometimes even 1:n::organization:devs. The transport security is moot when the user(s) discard all precautions and best practices on either end.
  - Avamander 1y ago
    Even in such cases it's not really moot if a forward-secure scheme is used, only old legacy implementations might not by now. So just the key being shared between machines does usually not compromise the security of individual sessions, especially not retroactively.
- MrDarcy 1y ago
  The platform engineering team at my big corp work simply disabled host key checking in the cloud tool Python script they wrote for all of us to log into our bastion hosts. For prod. ssh —-known-hosts-file=/dev/null
  - 20after4 1y ago
    Wow, that is a level of DGAF I haven't encountered before in production. No wonder data breaches are so common with that kind of YOLO security practices.
    - MrDarcy 1y ago
      To be fair, it’s all EC2 so provenance of the host is well established.
- ghusto 1y ago
  Please let's not break something that works really well just to cater to those who don't know how to use the tools of their trade.
blenderob 1y ago
> TOFU schemes aren't acceptable for the public web because the average user (1) isn't equipped to compare certificate fingerprints for their bank This! Forget about average user. As a technical user too I don't know how I would compare fingerprints every single time without making a mistake. I could install software or write my own to do this on desktop but what would I do on cell phones? And TOFU requires "trust" on first use. How do I make sure that if I should be trusting the website public key on first use? It doesn't seem like any easier to solve than PKI.
- Avamander 1y ago
  > How do I make sure that if I should be trusting the website public key on first use? It doesn't seem like any easier to solve than PKI. Usually such questions get replied to with a recommendation of implementing DNSSEC. Which is also obviously PKI and in many ways worse than WebPKI.
- akerl_ 1y ago
  This is the sleight of hand being employed when folks suggest TOFU mechanisms. The problem with any communication boils down to trust. The modern web PKI has a bunch of complexity and a plenty of rough edges in how it handles resolving that trust. TOFU is then proposed as a simpler solution with none of those pesky rough edges, but it doesn't have the rough edges because it leaves all the hard parts as an exercise for the reader. It's a bit like suggesting that AES-GCM has risks so we ought to just switch to one-time-pads.
- perching_aix 1y ago
  It's the usual hilarious flow of "HTTPS is dogshit, so here's the SSH fingerprint you should trust instead, served over HTTPS of course".
  - arielcostas 1y ago
    SSH fingerprints can also be provided via DNS with the SSHFP[0] DNS record, which coupled with DNSSEC and supposing you trust the DNS root and intermediate entities (whether that's IANA/ICANN, or alternatives like OpenNIC or Namecoin) allows you to check the SSH server fingerprints without HTTPS. At some point you probably need to trust someone anyway. Or you can always get the fingerprint out of band. If it's some friend granting you SSH access to their server, or a vendor, or whatever, you can ask them to write the fingerprint on a piece of paper and give it to you, with you checking the paper comes from them and then checking them. [0]: https://datatracker.ietf.org/doc/html/rfc4255 https://datatracker.ietf.org/doc/html/rfc4255

ericbarrett 1y ago

Does it even work great for nerds? I have seen a distressing amount of turning host key warnings off, or ignoring the warnings forever, or replacing a host key without any curiosity or investigation. Seems even worse in the cloud, where systems change a lot.

woodruffw 1y ago
> Does it even work great for nerds? No, but I was extending a charitable amount of credulousness :-)
Spivak 1y ago
I think it's pretty reasonable to turn off the "yes i would like to accept this key" on first connect. Just scream if it ever changes. I get that they're expecting me to compare it to something out of band but nobody does that.
- blenderob 1y ago
  > I think it's pretty reasonable to turn off the "yes i would like to accept this key" on first connect. Why is it reasonable to trust the key on first use? What if the first use itself has a man-in-the-middle that presents you the middle-man's key? Why should I trust it on first use? How do I tell if the key belongs to the real website or to a middle-man website?
  - 1718627440 1y ago
    What is the "real website"? You do not know this in the general case, it is just some rando on the internet, which is indistinguishable from a middle-man.
    - Ferret7446 1y ago
      It is whoever owns the domain. The point is when your client talks to a domain, you know you are actually getting the domain, even if you don't know who owns it or if they're trustworthy. It removes an unnecessary variable.
      - 1718627440 1y ago
        Domain ownership is declared by someone randomly answering to a DNS request. If someone else answers, than what does it mean to "own a domain".
        blenderob 1y ago
        Not at all. I might have my own DNS server to answer my DNS request or I may trust a specific DNS server (not controlled by my ISP). My DNS entry may be 100% correct and resolving to my actual bank website. But with TOFU, on first use, it is still possible for a router/ISP/middle-man in between to intercept the response being served from the real website and serve a MITM certificate to me.
        1y ago
evilduck 1y ago
Even amongst nerds I've seen a significant amount of key pair re-use in my time, both 1:n::dev:servers and sometimes even 1:n::organization:devs. The transport security is moot when the user(s) discard all precautions and best practices on either end.
- Avamander 1y ago
  Even in such cases it's not really moot if a forward-secure scheme is used, only old legacy implementations might not by now. So just the key being shared between machines does usually not compromise the security of individual sessions, especially not retroactively.
MrDarcy 1y ago
The platform engineering team at my big corp work simply disabled host key checking in the cloud tool Python script they wrote for all of us to log into our bastion hosts. For prod. ssh —-known-hosts-file=/dev/null
- 20after4 1y ago
  Wow, that is a level of DGAF I haven't encountered before in production. No wonder data breaches are so common with that kind of YOLO security practices.
  - MrDarcy 1y ago
    To be fair, it’s all EC2 so provenance of the host is well established.
ghusto 1y ago
Please let's not break something that works really well just to cater to those who don't know how to use the tools of their trade.

blenderob 1y ago

> TOFU schemes aren't acceptable for the public web because the average user (1) isn't equipped to compare certificate fingerprints for their bank This! Forget about average user. As a technical user too I don't know how I would compare fingerprints every single time without making a mistake. I could install software or write my own to do this on desktop but what would I do on cell phones? And TOFU requires "trust" on first use. How do I make sure that if I should be trusting the website public key on first use? It doesn't seem like any easier to solve than PKI.

Avamander 1y ago
> How do I make sure that if I should be trusting the website public key on first use? It doesn't seem like any easier to solve than PKI. Usually such questions get replied to with a recommendation of implementing DNSSEC. Which is also obviously PKI and in many ways worse than WebPKI.
akerl_ 1y ago
This is the sleight of hand being employed when folks suggest TOFU mechanisms. The problem with any communication boils down to trust. The modern web PKI has a bunch of complexity and a plenty of rough edges in how it handles resolving that trust. TOFU is then proposed as a simpler solution with none of those pesky rough edges, but it doesn't have the rough edges because it leaves all the hard parts as an exercise for the reader. It's a bit like suggesting that AES-GCM has risks so we ought to just switch to one-time-pads.
perching_aix 1y ago
It's the usual hilarious flow of "HTTPS is dogshit, so here's the SSH fingerprint you should trust instead, served over HTTPS of course".
- arielcostas 1y ago
  SSH fingerprints can also be provided via DNS with the SSHFP[0] DNS record, which coupled with DNSSEC and supposing you trust the DNS root and intermediate entities (whether that's IANA/ICANN, or alternatives like OpenNIC or Namecoin) allows you to check the SSH server fingerprints without HTTPS. At some point you probably need to trust someone anyway. Or you can always get the fingerprint out of band. If it's some friend granting you SSH access to their server, or a vendor, or whatever, you can ask them to write the fingerprint on a piece of paper and give it to you, with you checking the paper comes from them and then checking them. [0]: https://datatracker.ietf.org/doc/html/rfc4255 https://datatracker.ietf.org/doc/html/rfc4255