3 ms·

It depends on what you care about more: certs being issued validly, or certs being issued? Processes can be put in place so that humans can fix problems when th

It depends on what you care about more: certs being issued validly, or certs being issued? Processes can be put in place so that humans can fix problems when they find them, but also prevent a human from doing the wrong thing. Autonomation instead of automation. https://en.wikipedia.org/wiki/Autonomation https://en.wikipedia.org/wiki/Autonomation

geofft 8y ago
I think it's reasonable to care more about certs being issued. Most large companies are incompetent at IT (and the reasons for this are varied and interesting but not immediately solvable), yet if they can't reliably get certificates, the plan to encrypt all web traffic falls apart. Meanwhile, Certificate Transparency monitoring mitigates the impact of mis-issuance. (Which is not to say that mis-issuance isn't great, just that it's fine to target a system that occasionally produces mis-issuances.) I guess in part I feel this way because I see HTTPS as baseline security for the web, not strong security. It's like SSH - the fact that telnet is almost completely gone is a win, even though few people really check the initial fingerprints the way they "should." In the case of both HTTPS and SSH, you can build a strong security system on top of it if you want (HPKP, pinned certs in apps, etc. for HTTPS, and distributing known_hosts files or using a private PKI or Kerberos for SSH), but the primary value is that it works reliably to the point where falling back to plaintext is unusual.
- heavenlyblue 8y ago
  >> even though few people really check the initial fingerprints the way they "should." I am yet to see a single hosting provider which doesn’t only allow you to set up your own authorizarion key in a new instance, but which also immediately gives you the generated key of the instance that you can put in the .ssh/known_hosts. So frankly it’s not just “people”.
  - geofft 8y ago
    AWS (and more generally anything running cloud-init) does this fairly well - it prints it to the console log. I use this, and I have on a couple of occasions booted a new instance and mounted the old one's disk when my known_hosts file got trashed by mistake, so I could re-establish a trust path. Of course you have to know to go there, wait for the console log to sync (for some reason AWS takes a few minutes ... I wonder if it's backed by some eventual-consistency object store), and scroll down in the log. Come to think of it, it would be real cool if OpenSSH had a -o Fingerprint=ab:cd:ef... option you could pass, so that they could give you a single command to copy and paste to your terminal.
- peterwwillis 8y ago
  HTTPS is a good enough baseline if all you care about is doing business. If you're an individual trying to protect yourself online, it's not a good baseline. SSH is a good example of this. You can totally MITM brand new SSH connections all day, because nobody ever checks the fingerprint (and virtually all server-side automation just ignores them completely). The only attacker we actually care about with SSH is a really stupid one who thinks that trying to MITM every session at random will actually succeed. (It won't.) If the attacker is smart, they'll use targeted attacks in ways that they are more likely to find a first-try connection, and MITM that. So, why do we use SSH? Because it mostly defeats the dumbest possible attacks. With HTTPS, instead of the attacker targeting a user, the attacker [in the future] targets cert creation. If they succeed, they get full MITM; if they fail, they lose nothing. And they get to keep trying, on every single damn CA, and on any target site they choose. So, why do we even use HTTPS? Because it solidly defeats the dumbest possible attacks. Neither of these are good baselines, but with HTTPS it's even worse, because the user has no way of defending themselves. At least with SSH I can enforce my own known_hosts file. With HTTPS, I am at the mercy of the electronic gods that maintain my browser and generate certs. And (importantly, I think) if someone compromises my SSH connection, at worst they get to control my server. Oh noooo! There goes my private git repo! Whereas if they MITM my HTTPS connection, they get my retirement fund. HTTPS is like a wall that surrounds the village, built by the tribal leaders. We can't touch it, except to climb the rungs of ladders built into the wall. It will keep out the wolves, but not enemy soldiers. For now, it's good enough at keeping the wolves at bay, so we still use it. But one day soon the wolves will learn to climb ladders. https://www.youtube.com/watch?v=G_cTl4wR81Q https://www.youtube.com/watch?v=G_cTl4wR81Q

geofft 8y ago

I think it's reasonable to care more about certs being issued. Most large companies are incompetent at IT (and the reasons for this are varied and interesting but not immediately solvable), yet if they can't reliably get certificates, the plan to encrypt all web traffic falls apart. Meanwhile, Certificate Transparency monitoring mitigates the impact of mis-issuance. (Which is not to say that mis-issuance isn't great, just that it's fine to target a system that occasionally produces mis-issuances.) I guess in part I feel this way because I see HTTPS as baseline security for the web, not strong security. It's like SSH - the fact that telnet is almost completely gone is a win, even though few people really check the initial fingerprints the way they "should." In the case of both HTTPS and SSH, you can build a strong security system on top of it if you want (HPKP, pinned certs in apps, etc. for HTTPS, and distributing known_hosts files or using a private PKI or Kerberos for SSH), but the primary value is that it works reliably to the point where falling back to plaintext is unusual.

heavenlyblue 8y ago
>> even though few people really check the initial fingerprints the way they "should." I am yet to see a single hosting provider which doesn’t only allow you to set up your own authorizarion key in a new instance, but which also immediately gives you the generated key of the instance that you can put in the .ssh/known_hosts. So frankly it’s not just “people”.
- geofft 8y ago
  AWS (and more generally anything running cloud-init) does this fairly well - it prints it to the console log. I use this, and I have on a couple of occasions booted a new instance and mounted the old one's disk when my known_hosts file got trashed by mistake, so I could re-establish a trust path. Of course you have to know to go there, wait for the console log to sync (for some reason AWS takes a few minutes ... I wonder if it's backed by some eventual-consistency object store), and scroll down in the log. Come to think of it, it would be real cool if OpenSSH had a -o Fingerprint=ab:cd:ef... option you could pass, so that they could give you a single command to copy and paste to your terminal.
peterwwillis 8y ago
HTTPS is a good enough baseline if all you care about is doing business. If you're an individual trying to protect yourself online, it's not a good baseline. SSH is a good example of this. You can totally MITM brand new SSH connections all day, because nobody ever checks the fingerprint (and virtually all server-side automation just ignores them completely). The only attacker we actually care about with SSH is a really stupid one who thinks that trying to MITM every session at random will actually succeed. (It won't.) If the attacker is smart, they'll use targeted attacks in ways that they are more likely to find a first-try connection, and MITM that. So, why do we use SSH? Because it mostly defeats the dumbest possible attacks. With HTTPS, instead of the attacker targeting a user, the attacker [in the future] targets cert creation. If they succeed, they get full MITM; if they fail, they lose nothing. And they get to keep trying, on every single damn CA, and on any target site they choose. So, why do we even use HTTPS? Because it solidly defeats the dumbest possible attacks. Neither of these are good baselines, but with HTTPS it's even worse, because the user has no way of defending themselves. At least with SSH I can enforce my own known_hosts file. With HTTPS, I am at the mercy of the electronic gods that maintain my browser and generate certs. And (importantly, I think) if someone compromises my SSH connection, at worst they get to control my server. Oh noooo! There goes my private git repo! Whereas if they MITM my HTTPS connection, they get my retirement fund. HTTPS is like a wall that surrounds the village, built by the tribal leaders. We can't touch it, except to climb the rungs of ladders built into the wall. It will keep out the wolves, but not enemy soldiers. For now, it's good enough at keeping the wolves at bay, so we still use it. But one day soon the wolves will learn to climb ladders. https://www.youtube.com/watch?v=G_cTl4wR81Q https://www.youtube.com/watch?v=G_cTl4wR81Q