8 ms·

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

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.

ZWoz 4y ago
> HTTP is not ok. Anyone can ready / modify what is being sent. How do you plan demonstrate that in my local network, connection between my computer and printer web based interface? Generally, we had several decates HTTP as main protocol and that worked out.
- DANK_YACHT 4y ago
  The underlying assumption is that we're talking about the internet, not a private network, but even your private network would benefit from encryption. What is the benefit of having anyone with access to your network potentially read / modify your network traffic?
  - ZWoz 4y ago
    Browsers are being pretty weak to understand difference between local networks vs internet. Lot of times I have seen hassle caused by HTTPS, be it printer or server baseboard management controller.
    - cmeacham98 4y ago
      Citation needed. Firefox HTTPS only mode does not upgrade local IP addresses or reserved local "TLDs" like .local. If machines on your "local network" are squatting on a public IP or potentially public domain name how is the browser supposed to know the difference?
      - nybble41 4y ago
        > Firefox HTTPS only mode does not upgrade local IP addresses or reserved local "TLDs" like .local. If machines on your "local network" are squatting on a public IP… It could be one of your public IP addresses—more likely with IPv6, but still possible with IPv4—and not simply "squatting" on someone else's assigned public IP address. The browser may not be aware that these are local. With that said, the devices should use public domain names and obtain proper certificates for them via the ACME DNS challenge, which avoids the issue altogether.
    - seiferteric 4y ago
      An issue I don't think is addressed is how do you get a valid certificate for a server on a local network? Like setting a new device or router, you often type in the IP address (or maybe mDN name), then you either have to use http, or for https you get a warning and have to add an exception for an invalid certificate... How would one even solve this issue on a local network? I had an idea that I was thinking would be a cool RFC, have the router run a CA, then pass a DHCP (or RA) option with a local CA certificate for the end-user device to trust. Then services could request server certs from it (via ACME protocol). The issue though is that this gives too much power to the network operator. Imagine connecting to wifi at a coffee shop and they decide to MITM your google connections...
- necovek 4y ago
  If I've got a powerful enough wifi emitter, I could get close to your home and impersonate your AP using the same SSID (with open access). If you accidentally connect to it without paying attention, all unencrypted traffic is mine to record and modify. HTTPS solves that too.
superkuh 4y ago
It's like wearing a bulky level 3 bullet proof vest while you're at home cooking dinner. Yeah, it's keeping you safer. There's no doubt about that. The real dangers on the web come from the insane behavior of running all arbitrary code sent to the browser from anywhere. Like opening every email attachment you get sent. NoScript temp whitelist only provides a lot more safety than HTTPS Everywhere and doesn't give all power to a few corporations.
- DANK_YACHT 4y ago
  You need HTTPS to even begin trusting remote code. For instance, you download uMatrix to setup a whitelist. Where did uMatrix come from? If you downloaded it over HTTP, then you could be running anything. Even if you have a checksum for uMatrix, you can't trust it if you got the checksum over HTTP. Now let's say you installed uMatrix and you want to trust a script. Well, how do you know that the script you downloaded came from the URL you've allowed? If you've requested this script before, then you can use a content hash, but if not, then you're basically blindly trusting that no one has tampered with the data.
  - peoplefromibiza 4y ago
    > Where did uMatrix come from? But is uMatrix to trust? Can you trust uMatrix developers? I have bought a pair of shoes from an HTTPS only web sites, shoes never arrived, HTTPS apparently can't fix everything. Trusting trust is a problem since computing was invented. [1] [1] WARNING! PDF! https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
    - danShumway 4y ago
      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.
peoplefromibiza 4y ago
> HTTP is not ok actually, it is. HTTP is perfectly fine. [1] > Anyone can ready / modify what is being sent Anyone can break a window and enter my house. But I haven't aired a private army to patroll the windows. NSA can break HTTPS, TGF exists and China Trusted SSL Certificates are a thing. False sense of security is often more dangerous than a real sense of insecurity. Edit: [1] how many of you don't terminate SSL at load balancer?
- DANK_YACHT 4y ago
  So because the government can potentially decrypt your traffic, you don't care if anyone can? Do you use online banking? Do you care if you transmit your password to your bank account in plaintext? What if you need to call your bank? Would you really trust a phone number delivered over HTTP? That just seems crazy to me.
  - peoplefromibiza 4y ago
    > you don't care if anyone can? that's a very bald assumption, my dear friend. But in practice, yes, it is safe do not care of the possibility that someone is going to inject a script in your blog header, because I am no police officer, I do not work overtime, fighting crime. [1] Same way I'm not worried that someone is going to steal my car and use it to rob a bank or worse. > Do you use online banking? Banks also have guards at the doors. They handle other people's money, of course they care about it and about the safety of their employees. Are you a bank? > Do you care if you transmit your password to your bank account in plaintext? Not really. 99% of my passwords are passw0rd on websites I really don't care about. It is much harder, if not impossible, to guess my username. I bet I am not the only one. Besides, my bank ask me to confirm any operation in a MFA way. If they notice something strange, they call me, on my phone, a human calls me. It's their job. > Would you really trust a phone number delivered over HTTP? I've trusted for the majority of my life phone numbers sent unencrypted through wires that everybody could wiretap to and then by email... Nothing bad ever happened. Besides, what can happen if you call the wrong number? I do not believe that the Grudge is a real story. The point is: no, I am not paranoid. Common sense is enough 99% of the times. [1] https://www.youtube.com/watch?v=o2Z1yLO9C-Q https://www.youtube.com/watch?v=o2Z1yLO9C-Q
at_a_remove 4y ago
We've had more security alerts from OpenSSL and other cert-related software than the man-in-the-middle attacks.
- GeorgeTirebiter 4y ago
  To be fair: if there were successful MIM attacks by the black hats -- how would we know?
  - at_a_remove 4y ago
    To be fair ... that's true of most attacks.

ZWoz 4y ago

> HTTP is not ok. Anyone can ready / modify what is being sent. How do you plan demonstrate that in my local network, connection between my computer and printer web based interface? Generally, we had several decates HTTP as main protocol and that worked out.

DANK_YACHT 4y ago
The underlying assumption is that we're talking about the internet, not a private network, but even your private network would benefit from encryption. What is the benefit of having anyone with access to your network potentially read / modify your network traffic?
- ZWoz 4y ago
  Browsers are being pretty weak to understand difference between local networks vs internet. Lot of times I have seen hassle caused by HTTPS, be it printer or server baseboard management controller.
  - cmeacham98 4y ago
    Citation needed. Firefox HTTPS only mode does not upgrade local IP addresses or reserved local "TLDs" like .local. If machines on your "local network" are squatting on a public IP or potentially public domain name how is the browser supposed to know the difference?
    - nybble41 4y ago
      > Firefox HTTPS only mode does not upgrade local IP addresses or reserved local "TLDs" like .local. If machines on your "local network" are squatting on a public IP… It could be one of your public IP addresses—more likely with IPv6, but still possible with IPv4—and not simply "squatting" on someone else's assigned public IP address. The browser may not be aware that these are local. With that said, the devices should use public domain names and obtain proper certificates for them via the ACME DNS challenge, which avoids the issue altogether.
  - seiferteric 4y ago
    An issue I don't think is addressed is how do you get a valid certificate for a server on a local network? Like setting a new device or router, you often type in the IP address (or maybe mDN name), then you either have to use http, or for https you get a warning and have to add an exception for an invalid certificate... How would one even solve this issue on a local network? I had an idea that I was thinking would be a cool RFC, have the router run a CA, then pass a DHCP (or RA) option with a local CA certificate for the end-user device to trust. Then services could request server certs from it (via ACME protocol). The issue though is that this gives too much power to the network operator. Imagine connecting to wifi at a coffee shop and they decide to MITM your google connections...
necovek 4y ago
If I've got a powerful enough wifi emitter, I could get close to your home and impersonate your AP using the same SSID (with open access). If you accidentally connect to it without paying attention, all unencrypted traffic is mine to record and modify. HTTPS solves that too.

superkuh 4y ago

It's like wearing a bulky level 3 bullet proof vest while you're at home cooking dinner. Yeah, it's keeping you safer. There's no doubt about that. The real dangers on the web come from the insane behavior of running all arbitrary code sent to the browser from anywhere. Like opening every email attachment you get sent. NoScript temp whitelist only provides a lot more safety than HTTPS Everywhere and doesn't give all power to a few corporations.

DANK_YACHT 4y ago
You need HTTPS to even begin trusting remote code. For instance, you download uMatrix to setup a whitelist. Where did uMatrix come from? If you downloaded it over HTTP, then you could be running anything. Even if you have a checksum for uMatrix, you can't trust it if you got the checksum over HTTP. Now let's say you installed uMatrix and you want to trust a script. Well, how do you know that the script you downloaded came from the URL you've allowed? If you've requested this script before, then you can use a content hash, but if not, then you're basically blindly trusting that no one has tampered with the data.
- peoplefromibiza 4y ago
  > Where did uMatrix come from? But is uMatrix to trust? Can you trust uMatrix developers? I have bought a pair of shoes from an HTTPS only web sites, shoes never arrived, HTTPS apparently can't fix everything. Trusting trust is a problem since computing was invented. [1] [1] WARNING! PDF! https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
  - danShumway 4y ago
    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.

peoplefromibiza 4y ago

> HTTP is not ok actually, it is. HTTP is perfectly fine. [1] > Anyone can ready / modify what is being sent Anyone can break a window and enter my house. But I haven't aired a private army to patroll the windows. NSA can break HTTPS, TGF exists and China Trusted SSL Certificates are a thing. False sense of security is often more dangerous than a real sense of insecurity. Edit: [1] how many of you don't terminate SSL at load balancer?

DANK_YACHT 4y ago
So because the government can potentially decrypt your traffic, you don't care if anyone can? Do you use online banking? Do you care if you transmit your password to your bank account in plaintext? What if you need to call your bank? Would you really trust a phone number delivered over HTTP? That just seems crazy to me.
- peoplefromibiza 4y ago
  > you don't care if anyone can? that's a very bald assumption, my dear friend. But in practice, yes, it is safe do not care of the possibility that someone is going to inject a script in your blog header, because I am no police officer, I do not work overtime, fighting crime. [1] Same way I'm not worried that someone is going to steal my car and use it to rob a bank or worse. > Do you use online banking? Banks also have guards at the doors. They handle other people's money, of course they care about it and about the safety of their employees. Are you a bank? > Do you care if you transmit your password to your bank account in plaintext? Not really. 99% of my passwords are passw0rd on websites I really don't care about. It is much harder, if not impossible, to guess my username. I bet I am not the only one. Besides, my bank ask me to confirm any operation in a MFA way. If they notice something strange, they call me, on my phone, a human calls me. It's their job. > Would you really trust a phone number delivered over HTTP? I've trusted for the majority of my life phone numbers sent unencrypted through wires that everybody could wiretap to and then by email... Nothing bad ever happened. Besides, what can happen if you call the wrong number? I do not believe that the Grudge is a real story. The point is: no, I am not paranoid. Common sense is enough 99% of the times. [1] https://www.youtube.com/watch?v=o2Z1yLO9C-Q https://www.youtube.com/watch?v=o2Z1yLO9C-Q

at_a_remove 4y ago

We've had more security alerts from OpenSSL and other cert-related software than the man-in-the-middle attacks.

GeorgeTirebiter 4y ago
To be fair: if there were successful MIM attacks by the black hats -- how would we know?
- at_a_remove 4y ago
  To be fair ... that's true of most attacks.