5 ms·
How did we exchange phone numbers? I need to know your phone number to verify the hash I receive via text message.
by 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 agoOk, 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.
- peoplefromibiza 4y ago> I mentioned this above, but when was Debian ever doing this? I They are still doing it! On my system (this one's not Debian, but KDE Neon) $ cat /etc/apt/sources.list deb http://archive.ubuntu.com/ubuntu/ focal main restricted universe multiverse deb http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse > That's not what HTTPS protects against, HTTPS is designed to protect against MITM attacks That need a MITM Which is a specific type of attack. If you are running a network where that's not possible, you're fine. > LetsEncrypt pretty much only cares whether or not you control the domain you say you control LetsEncrypt is pretty much an advanced tool, for advanced users > I don't personally like when companies do this, but it's not breaking HTTPS. It's breaking confidentiality. Which is one of the features of HTTPS In a corporate network MITM attacks are not that easy to pull off. So basically HTTPS main feature is encryption of content in that context. > Carrots and spinach are not a health panacea, but that doesn't mean I'm obligated to eat dirt instead. first of all, carrots and spinach are a panacea. Secondly, HTTP is not dirt. Like SMTP is not dirt and IRC is not dirt and FTP is not dirt and TFTP is not dirt > But that doesn't mean HTTP is secure. an ex nobody said HTTP is secure, but it's not inherently insecure, like every plain text protocol it's plain text. it's the network that is insecure, MITM is not an exclusive of HTTP. If the network is secure, HTTP is secure. In my kubernetes clusters, TLS is terminated at load balancer and PODS talk to each other using plain simple HTTP. Wasting energy on useless cryptography "just because" is not very smart IMO.