5 ms·

> The only reason you should open port 80 on your server is to redirect all requests to port 443 and then close the connection on port 80. (Someday, maybe we ca

by bArray 5y ago

> The only reason you should open port 80 on your server is to redirect all requests to port 443 and then close the connection on port 80. (Someday, maybe we can drop port 80 altogether.) I think it is fine to support both if you are not handling forms, etc. Obviously you prefer people to use HTTPS, but there may be cases where HTTP is preferred. One example might be a large download where you can verify the hash afterwards, or interacting with old hardware/software.

dijit 5y ago
I think the biggest bug bear with this approach (an approach I agree with, fwiw) is that the content of a page can be modified to include malicious content, including legitimate looking forms. This wasn’t really a widespread problem before “https everywhere” became a thing, but it’s definitely possible. I distinctly remember projects that replaced images with cat pictures in-line, or made everything upside down; by exploiting the fact that can be modified in transit.
- bArray 5y ago
  > [..] a page can be modified to include malicious content, including legitimate looking forms. Sure, I've been there with "free WiFi" services injecting crap into a page. I believe some ISPs in the US would also put JS into HTTP pages. But this is why I argue for both HTTP and HTTPS. I think it ultimately depends on your security model. Perhaps a workaround could be to disable forms in browsers whilst in HTTP mode, disable JS, parts of CSS, etc, by default. Require that the user explicitly ask for content in an insecure way.
staticassertion 5y ago
I seriously doubt that encryption/decryption is going to bottleneck a large download as opposed to network overhead.
- bArray 5y ago
  > I seriously doubt that encryption/decryption is going to bottleneck a large download as opposed to network overhead. I think it really depends on the scale of what you're working with. It's not just the network overhead but also the CPU overhead. It's the cost of a copy operation (and maybe not even that with io_uring) vs an entire encryption process.

by bArray 5y ago

dijit 5y ago

I think the biggest bug bear with this approach (an approach I agree with, fwiw) is that the content of a page can be modified to include malicious content, including legitimate looking forms. This wasn’t really a widespread problem before “https everywhere” became a thing, but it’s definitely possible. I distinctly remember projects that replaced images with cat pictures in-line, or made everything upside down; by exploiting the fact that can be modified in transit.

bArray 5y ago
> [..] a page can be modified to include malicious content, including legitimate looking forms. Sure, I've been there with "free WiFi" services injecting crap into a page. I believe some ISPs in the US would also put JS into HTTP pages. But this is why I argue for both HTTP and HTTPS. I think it ultimately depends on your security model. Perhaps a workaround could be to disable forms in browsers whilst in HTTP mode, disable JS, parts of CSS, etc, by default. Require that the user explicitly ask for content in an insecure way.

staticassertion 5y ago

I seriously doubt that encryption/decryption is going to bottleneck a large download as opposed to network overhead.

bArray 5y ago
> I seriously doubt that encryption/decryption is going to bottleneck a large download as opposed to network overhead. I think it really depends on the scale of what you're working with. It's not just the network overhead but also the CPU overhead. It's the cost of a copy operation (and maybe not even that with io_uring) vs an entire encryption process.