4 ms·

I send you a file over HTTP and then I send you an SMS with the sha256 hash that you can verify Even if SMS are "easy" to intercept, even if I send you an emai

I send you a file over HTTP and then I send you an SMS with the sha256 hash that you can verify Even if SMS are "easy" to intercept, even if I send you an email with the SHA256, using a side channel greatly improve security, unless you're being targeted on multiple channels, which is quite uncommon. For the same reason, even an MD5 hash is good enough most of the times. Even if it's been proven not secure years ago, it's secure enough to trust that in the general case the odds of generating the same hash while also creating something that is not simply broken, but it's malicious, are very, very low and require effort. the point is: HTTPS still relies on trusting things we can't control and we will probably never control. We are forced to trust HTTPS because there is nothing more we can do. > But I'd rather not make that even harder by allowing basically anyone to intercept and modify the code that uMatrix is sending at any time. But the reality is that it is hardly "everyone" a MITM must be, by definition, in the middle. Debian survived for decades delivering their packages over HTTP

DANK_YACHT 4y ago
How did we exchange phone numbers? I need to know your phone number to verify the hash I receive via text message.
- peoplefromibiza 4y ago
  > How did we exchange phone numbers? I used HTTPS so our common friend at NSA knew what it was and sent a pigeon to your house. How do you know that once you verified the hash, the software is safe?
  - DANK_YACHT 4y ago
    Ok, so the NSA could have replaced the phone numbers we sent each other, which means that we can't be sure that the NSA isn't intercepting our file transfer later, which is the exact same issue we would face had we using HTTPS to transfer the file, except we did a lot more work (e.g. exchanged numbers, texted file hashes, compared check sums, etc.). btw, citation needed that the NSA is able to decrypt https traffic.
    - peoplefromibiza 4y ago
      > Ok, so the NSA could have replaced the phone numbers we sent each other What if we're living in a black hole and our universe is a white hole? > except we did a lot more work Or we trust the sender to not be malevolent and/or compromised, like Debian did for more than 20 years. I don't understand why people live like they are surrounded by enemies in enemy territory, given it's not usually the case. HTTP is perfectly fine, unless you have reason to not use HTTP. They exists, but it's not always necessary. Also: 99% of corporate networks install self signed certs and override the certification authority, so traffic is inspectable. Some mobile network operators do the same things when they sell to customers "secure network" upgrades. HTTPS is not a panacea. You simply trust a different set of "authorities" that none of us know or control.
      - danShumway 4y ago
        > Or we trust the sender to not be malevolent and/or compromised, like Debian did for more than 20 years. I mentioned this above, but when was Debian ever doing this? I don't think I've ever used a package manager that wasn't at least making some attempt to secure against MITM attacks and compromised CDNs. > Or we trust the sender to not be malevolent and/or compromised That's not what HTTPS protects against, HTTPS is designed to protect against MITM attacks. It doesn't inherently have anything to do with verifying identity, and we've actively moved away from identity verification in the SSL world, because the companies trying to do identity verification to determine which certificates were "verified" added very little security to the process and were mostly a waste of money. LetsEncrypt pretty much only cares whether or not you control the domain you say you control. It doesn't verify your identity past that point, because that's not its job. It solves a specific problem. > Also: 99% of corporate networks install self signed certs and override the certification authority, so traffic is inspectable. I don't personally like when companies do this, but it's not breaking HTTPS. If the user or device owner imports a certificate authority, then the browser should trust it. Isn't that the whole criticism people have with HTTPS, that they don't like gatekeepers? They should be happy that device owners can swap out certificate authorities. > HTTPS is not a panacea. Carrots and spinach are not a health panacea, but that doesn't mean I'm obligated to eat dirt instead. There are definitely alternative schemes that could be used in the browser other than HTTPS. It's OK if you don't like HTTPS in specific. But that doesn't mean HTTP is secure.
danShumway 4y ago
> and then I send you an SMS with the sha256 hash that you can verify Your blog isn't doing that, and none of your readers are verifying the hashes. If signature checks aren't being done automatically within the software, then for all practical purposes they might as well not exist for the vast majority of people. Sending an SMS with a sha256 is bad security because for the average person it is equivalent to just sending them an SMS message. They will not verify the sha256 and it is impossible to train them to. And sure, I use SMS for some stuff, but I don't pretend that it's secure or that encrypted messaging doesn't matter because trusting trust isn't a solved problem yet. > Debian survived for decades delivering their packages over HTTP No, Debian used what is essentially their own certificate authority (PGP and Web of Trust). Your blog does not have the same security guarantees as Debian's package manager, and the fact that Debian relies on package signing using PGP and Web of Trust is strong evidence that they do believe that in-software automatic verification of message integrity is important for delivering code. Everyone acts like Debian is proof that you don't need security, but package managers throw error messages when package signatures are wrong, just like your browser does when it can't verify an SSL cert. Because in both cases, verifying message integrity matters, even though it doesn't get rid of the entire problem of trust on its own. > But the reality is that it is hardly "everyone" [...] a MITM must be, by definition, in the middle. It's enough people. It doesn't have to literally be everyone on the entire planet. You should not be multiplying your attack vectors unnecessarily when there are trivially implemented, free, widely available methods for removing those attack vectors. ---- What a lot of this boils down to: > For the same reason, even an MD5 hash is good enough most of the times. There is a difference between leaving your shed unlocked because you're hoping your neighborhood is nice and no one will steal your lawnmower, and going onto a forum and arguing that locks are unnecessary because you leave your shed unlocked. What you are essentially arguing here is not that HTTP is secure, you are arguing that bad security is OK. Which, fine, make that argument if you want, but "I don't need to be secure" is very different from "HTTPS doesn't matter for security."

DANK_YACHT 4y ago

How did we exchange phone numbers? I need to know your phone number to verify the hash I receive via text message.

peoplefromibiza 4y ago
> How did we exchange phone numbers? I used HTTPS so our common friend at NSA knew what it was and sent a pigeon to your house. How do you know that once you verified the hash, the software is safe?
- DANK_YACHT 4y ago
  Ok, so the NSA could have replaced the phone numbers we sent each other, which means that we can't be sure that the NSA isn't intercepting our file transfer later, which is the exact same issue we would face had we using HTTPS to transfer the file, except we did a lot more work (e.g. exchanged numbers, texted file hashes, compared check sums, etc.). btw, citation needed that the NSA is able to decrypt https traffic.
  - peoplefromibiza 4y ago
    > Ok, so the NSA could have replaced the phone numbers we sent each other What if we're living in a black hole and our universe is a white hole? > except we did a lot more work Or we trust the sender to not be malevolent and/or compromised, like Debian did for more than 20 years. I don't understand why people live like they are surrounded by enemies in enemy territory, given it's not usually the case. HTTP is perfectly fine, unless you have reason to not use HTTP. They exists, but it's not always necessary. Also: 99% of corporate networks install self signed certs and override the certification authority, so traffic is inspectable. Some mobile network operators do the same things when they sell to customers "secure network" upgrades. HTTPS is not a panacea. You simply trust a different set of "authorities" that none of us know or control.
    - danShumway 4y ago
      > Or we trust the sender to not be malevolent and/or compromised, like Debian did for more than 20 years. I mentioned this above, but when was Debian ever doing this? I don't think I've ever used a package manager that wasn't at least making some attempt to secure against MITM attacks and compromised CDNs. > Or we trust the sender to not be malevolent and/or compromised That's not what HTTPS protects against, HTTPS is designed to protect against MITM attacks. It doesn't inherently have anything to do with verifying identity, and we've actively moved away from identity verification in the SSL world, because the companies trying to do identity verification to determine which certificates were "verified" added very little security to the process and were mostly a waste of money. LetsEncrypt pretty much only cares whether or not you control the domain you say you control. It doesn't verify your identity past that point, because that's not its job. It solves a specific problem. > Also: 99% of corporate networks install self signed certs and override the certification authority, so traffic is inspectable. I don't personally like when companies do this, but it's not breaking HTTPS. If the user or device owner imports a certificate authority, then the browser should trust it. Isn't that the whole criticism people have with HTTPS, that they don't like gatekeepers? They should be happy that device owners can swap out certificate authorities. > HTTPS is not a panacea. Carrots and spinach are not a health panacea, but that doesn't mean I'm obligated to eat dirt instead. There are definitely alternative schemes that could be used in the browser other than HTTPS. It's OK if you don't like HTTPS in specific. But that doesn't mean HTTP is secure.

danShumway 4y ago

> and then I send you an SMS with the sha256 hash that you can verify Your blog isn't doing that, and none of your readers are verifying the hashes. If signature checks aren't being done automatically within the software, then for all practical purposes they might as well not exist for the vast majority of people. Sending an SMS with a sha256 is bad security because for the average person it is equivalent to just sending them an SMS message. They will not verify the sha256 and it is impossible to train them to. And sure, I use SMS for some stuff, but I don't pretend that it's secure or that encrypted messaging doesn't matter because trusting trust isn't a solved problem yet. > Debian survived for decades delivering their packages over HTTP No, Debian used what is essentially their own certificate authority (PGP and Web of Trust). Your blog does not have the same security guarantees as Debian's package manager, and the fact that Debian relies on package signing using PGP and Web of Trust is strong evidence that they do believe that in-software automatic verification of message integrity is important for delivering code. Everyone acts like Debian is proof that you don't need security, but package managers throw error messages when package signatures are wrong, just like your browser does when it can't verify an SSL cert. Because in both cases, verifying message integrity matters, even though it doesn't get rid of the entire problem of trust on its own. > But the reality is that it is hardly "everyone" [...] a MITM must be, by definition, in the middle. It's enough people. It doesn't have to literally be everyone on the entire planet. You should not be multiplying your attack vectors unnecessarily when there are trivially implemented, free, widely available methods for removing those attack vectors. ---- What a lot of this boils down to: > For the same reason, even an MD5 hash is good enough most of the times. There is a difference between leaving your shed unlocked because you're hoping your neighborhood is nice and no one will steal your lawnmower, and going onto a forum and arguing that locks are unnecessary because you leave your shed unlocked. What you are essentially arguing here is not that HTTP is secure, you are arguing that bad security is OK. Which, fine, make that argument if you want, but "I don't need to be secure" is very different from "HTTPS doesn't matter for security."