Now, if only we could become better at securely managing keys.
HTTPS Everywhere will sunset in January 2023
101–110 of 148 posts
Re: HTTPS Everywhere will sunset in January 2023
#102Earlier quoted context omitted.
Without some kind of baseline for secure connections you can't even start approaching the problem of trusting trust. Yes, it's hard to figure out whether or not to trust uMatrix. 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.
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,…
How did we exchange phone numbers? I need to know your phone number to verify the hash I receive via text message.
Re: HTTPS Everywhere will sunset in January 2023
#103Earlier quoted context omitted.
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,…
How did we exchange phone numbers? I need to know your phone number to verify the hash I receive via text message.
> 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?
Re: HTTPS Everywhere will sunset in January 2023
#104Earlier quoted context omitted.
Right, but that's not HTTPS Everywhere. HTTPS Everywhere was "this site already has HTTPS, and really should only use that, but doesn't, so we'll redirect you to the HTTPS version". Now sites that have HTTPS default to it, and browsers have options to basically try https first and see if it works.
Should have been called "HTTPS as long as its already there". "HTTPS Everywhere" is pretty suggestive. And the English meaning of the words might be a worthwhile goal too.
Was there any confusion about the plugin creating an HTTPS capability where one doesn't exist? I always understood the outcome to be very clear.
Re: HTTPS Everywhere will sunset in January 2023
#105Earlier quoted context omitted.
How did we exchange phone numbers? I need to know your phone number to verify the hash I receive via text message.
> 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?
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.
Re: HTTPS Everywhere will sunset in January 2023
#106Earlier quoted context omitted.
> 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?
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.
> 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.
Re: HTTPS Everywhere will sunset in January 2023
#107Earlier quoted context omitted.
HTTP is not ok. Anyone can ready / modify what is being sent. This privacy intrusion will definitely happen, whereas the risk of being banned by "some external corporation" is low. And, you always have the option of self-signing your own certificate, which is at least as secure as using HTTP, and much more secure if you can verify the certificate via a side channel.
We've had more security alerts from OpenSSL and other cert-related software than the man-in-the-middle attacks.
To be fair: if there were successful MIM attacks by the black hats -- how would we know?
Re: HTTPS Everywhere will sunset in January 2023
#108Earlier quoted context omitted.
Eh, kind of. It's successful as far as the Internet, which is great. But Internet web pages isn't everything. There's still a real issue with infrastructre that has web configuration. Everything from home routers to video cameras and so on. Not being able to ship with a certificate that passes browser security checks is a problem that essentially nobody has addressed. When people connect to an IOT device, they need t…
Couldn't browsers just designate the .local tld to not check for SSL certs and enforce that it resolves to an IP on the current network? Seems like a simple solution for this.
Lots of local devices already do such a lookup and there's a whole class of vulnerabilities based on it (DNS rebinding and friends).
I'd personally classify 192.168/16, 172.16/12, 10/8, 127/8, fe80/10, and ::1 as local networks, but that's simply not always the case. There are tons of universities and even business out there that use publicly routable addresses for clients and that approach is even the default for IPv6. You could be tempted to use the local network range as a "local" network but there are plenty of networks out there where that would mark foreign networks as "local". Then there are those who use 1.0.0.0/8 for local addresses because that subnet was previously unused and the 10 range already had a separate meaning.
Just verifying that .something (.local is already reserved, you shouldn't use it for internal device names even though it'll probably work) matches an internal IP doesn't add any security. You might as well mark HTTP to local IP addresses as a secure origin and not mess with certificates at all. I don't th9nk that's a very good idea.
With IPv6, there's a solution to this problem. You can provision certificates to globally unique IP addresses and possibly their hostname. I don't think there's a solution for IPv4 on most local networks, though.
Re: HTTPS Everywhere will sunset in January 2023
#109Earlier quoted context omitted.
Eh, kind of. It's successful as far as the Internet, which is great. But Internet web pages isn't everything. There's still a real issue with infrastructre that has web configuration. Everything from home routers to video cameras and so on. Not being able to ship with a certificate that passes browser security checks is a problem that essentially nobody has addressed. When people connect to an IOT device, they need t…
It's security theater, it's not meant to solve real problems for real people.
The year 2015 wants its flamewar back.
Re: HTTPS Everywhere will sunset in January 2023
#110Earlier quoted context omitted.
Without some kind of baseline for secure connections you can't even start approaching the problem of trusting trust. Yes, it's hard to figure out whether or not to trust uMatrix. 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.
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,…
> 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."