5 ms·

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

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.
        1718627440 1y ago
        So then the one answering to your HTTP request is the real website no? That's the MITM.
        blenderob 1y ago
        Why do you say I should consider the middle-man answering the request to be the real website? If I want to visit chase.com, I want to consider a server controlled by Chase (the company) to be the real website. PKI with a CA that attests the legal entity behind the website guarantees this. I agree with you that Let's Encrypt does not guarantee this. Is your comment scoped to Let's Encrypt only? If so, I agree. But if we're talking about PKI in general, it seems like a terrible compromise to me to consider a middle-man to be the real website. I guess we both disagree on a very fundamental point. To me it seems ridiculous to accept that it is reasonable to consider to the middle-man to be the real website. But to you it apparently makes sense. I am unable to understand why though.
        1718627440 1y ago
        I started this thread with this: > You do not know this in the general case, it is just some rando on the internet, which is indistinguishable from a middle-man. What I was talking about is this: I read some URL, maybe on HN. I do not know who sits behind it. The content can be malicious, but whether they were that when the IP packet was assembled, who knows? In fact what is the difference between the "MITM" and "the real one". If "the real one" has never even received my request and the "MITM" doesn't forward it, then the "MITM" isn't a middle man but my connection partner. All the protocols form TCP, DNS to IP and DHCP assume that the connection partner is the one answering. The contents can be deceptive or something, but this doesn't matter, because things on the internet in general come from people I don't know, should be taken with a grain of salt and don't matter in the real world. I don't care who is the middle man and who not, because both are the same to me. The only problem here is if you establish credentials with one party and then accidentally send them to another party, e.g. a user/password login. This is solved by TOFU. Note, that this issue is symmetric. I neither want to send data from "the real one" to the "MITM", but I also don't want credentials established with the "MITM" to be received by "the real one", because this is the third-party in this case. Consider Chase (the company) to provide food delivery. I visit the MITM's site, pay money to the MITM, the MITM serves me food. Where is the problem here outside of trademark issues? This problem only occurs when you have contact with Chase (the company) out-of-band. What you are talking about is something totally different. You want to be assured that when you "visit" chase.com you are talking with Chase (the company). This is not assured in the general case. Even if there is nothing malicious going on, someone that is not Chase (the company) can be the one answering that. That is on top of issues like goog1e.com. Yes, this is solved by - establishing out-of-band that chase.com is Chase (the company) - you inputting the correct string, not some look-a-like - nothing being wrong with address resolution - PKI with a CA that attest the legal entity Note that you still need out-of-band knowledge. What Let's Encrypt solves is that browsers don't like self-signed certificates. It would be also solved with self-signed certificates and TOFU. > Is your comment scoped to Let's Encrypt only? The article we are discussing this under criticizes Let's Encrypt. However due to the PKI hiding that you still need out-of-band data, we accepted the current state. This is what the article and I criticizes and why the problem isn't only with Let's Encrypt. In the now deleted comment you wrote: > Yes, this is one point where I agree with you. But no bank really use Let's Encrypt for certificates. Banks do use certification authority where the legal entity is validated. This essentially means that Let's Encrypt shouldn't be treated like a trustworthy certificate, which I think I actually would agree. But I wouldn't propose this, because that means we are back to square one before Let's Encrypt, and I couldn't host websites that the common people would visit. I think this problem can't be solved, before it is accepted that it shouldn't be solved by private companies, but by jurisdictions. It is essentially the age-old identity problem.
- jeroenhd 1y ago
  Depends on the server. A VM you just installed on your own machine? A lab machine on the proxmox cluster? Probably. A new cloud VM running in another city? I would trust it by default, but you don't have a lot of choice in many corporate environments. Funnily enough, there is a solution to this: SSH has a certificate authority system that will let your SSH clients trust the identity of a server if the hostkey is signed and matches the domain the SSH CA provided. Like with HTTPS, this sort of works if you're deploying stuff internally. No need to check fingerprints or anything, as long as whatever automation configured your new VM signs the generated host key. Essentially, you get DV certificates for SSH except you can't easily automate them with Let's Encrypt/ACME because SSH doesn't have tooling like that.
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.

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.
        1718627440 1y ago
        So then the one answering to your HTTP request is the real website no? That's the MITM.
        blenderob 1y ago
        Why do you say I should consider the middle-man answering the request to be the real website? If I want to visit chase.com, I want to consider a server controlled by Chase (the company) to be the real website. PKI with a CA that attests the legal entity behind the website guarantees this. I agree with you that Let's Encrypt does not guarantee this. Is your comment scoped to Let's Encrypt only? If so, I agree. But if we're talking about PKI in general, it seems like a terrible compromise to me to consider a middle-man to be the real website. I guess we both disagree on a very fundamental point. To me it seems ridiculous to accept that it is reasonable to consider to the middle-man to be the real website. But to you it apparently makes sense. I am unable to understand why though.
        1718627440 1y ago
        I started this thread with this: > You do not know this in the general case, it is just some rando on the internet, which is indistinguishable from a middle-man. What I was talking about is this: I read some URL, maybe on HN. I do not know who sits behind it. The content can be malicious, but whether they were that when the IP packet was assembled, who knows? In fact what is the difference between the "MITM" and "the real one". If "the real one" has never even received my request and the "MITM" doesn't forward it, then the "MITM" isn't a middle man but my connection partner. All the protocols form TCP, DNS to IP and DHCP assume that the connection partner is the one answering. The contents can be deceptive or something, but this doesn't matter, because things on the internet in general come from people I don't know, should be taken with a grain of salt and don't matter in the real world. I don't care who is the middle man and who not, because both are the same to me. The only problem here is if you establish credentials with one party and then accidentally send them to another party, e.g. a user/password login. This is solved by TOFU. Note, that this issue is symmetric. I neither want to send data from "the real one" to the "MITM", but I also don't want credentials established with the "MITM" to be received by "the real one", because this is the third-party in this case. Consider Chase (the company) to provide food delivery. I visit the MITM's site, pay money to the MITM, the MITM serves me food. Where is the problem here outside of trademark issues? This problem only occurs when you have contact with Chase (the company) out-of-band. What you are talking about is something totally different. You want to be assured that when you "visit" chase.com you are talking with Chase (the company). This is not assured in the general case. Even if there is nothing malicious going on, someone that is not Chase (the company) can be the one answering that. That is on top of issues like goog1e.com. Yes, this is solved by - establishing out-of-band that chase.com is Chase (the company) - you inputting the correct string, not some look-a-like - nothing being wrong with address resolution - PKI with a CA that attest the legal entity Note that you still need out-of-band knowledge. What Let's Encrypt solves is that browsers don't like self-signed certificates. It would be also solved with self-signed certificates and TOFU. > Is your comment scoped to Let's Encrypt only? The article we are discussing this under criticizes Let's Encrypt. However due to the PKI hiding that you still need out-of-band data, we accepted the current state. This is what the article and I criticizes and why the problem isn't only with Let's Encrypt. In the now deleted comment you wrote: > Yes, this is one point where I agree with you. But no bank really use Let's Encrypt for certificates. Banks do use certification authority where the legal entity is validated. This essentially means that Let's Encrypt shouldn't be treated like a trustworthy certificate, which I think I actually would agree. But I wouldn't propose this, because that means we are back to square one before Let's Encrypt, and I couldn't host websites that the common people would visit. I think this problem can't be solved, before it is accepted that it shouldn't be solved by private companies, but by jurisdictions. It is essentially the age-old identity problem.
jeroenhd 1y ago
Depends on the server. A VM you just installed on your own machine? A lab machine on the proxmox cluster? Probably. A new cloud VM running in another city? I would trust it by default, but you don't have a lot of choice in many corporate environments. Funnily enough, there is a solution to this: SSH has a certificate authority system that will let your SSH clients trust the identity of a server if the hostkey is signed and matches the domain the SSH CA provided. Like with HTTPS, this sort of works if you're deploying stuff internally. No need to check fingerprints or anything, as long as whatever automation configured your new VM signs the generated host key. Essentially, you get DV certificates for SSH except you can't easily automate them with Let's Encrypt/ACME because SSH doesn't have tooling like that.

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.