5 ms·

It is interesting that the main argument against staying http is one of social responsibility. Your static site isn't any more susceptible to attacks with http

It is interesting that the main argument against staying http is one of social responsibility. Your static site isn't any more susceptible to attacks with http only, but your users are. A bunch of MITM techniques are thwarted by only visiting https sites. Is that your problem as a webmaster? Since LE, I have taken up the position that it is easy, and I prefer https sites as a user, so I really don't have a good reason not to enable https. Also, an attack on my end users is an attack on my site. Anytime someone wants to see my content and gets something else, that is bad. If I can significantly raise the difficulty of doing that, why wouldn't I?

superkuh 7y ago
Did you not read my comment? I love HTTPs. I make sure all my websites have it available. But I also make sure there's an HTTP site too.
- bulatb 7y ago
  Offering HTTP allows MITM attackers to strip HTTPS from visitors who want it. HSTS can help, but the vector still exists. Optional security is not just an upgrade; it opens up a downgrade path from more secure to less.
  - zzzcpan 7y ago
    You can't securely disable http on websites, even if you are not offering it, because it still can be faked by a MITM attacker via proxying it to https. So removing http is pointless for security and only hurts legitimate uses. I guess this is also one of the reasons why "HSTS preload" exists. Also encryption is neither security nor privacy.
    - pixl97 7y ago
      Pray tell, how did you come to the conclusion that encryption is not security or privacy, and are you an Australian politician?
      - zzzcpan 7y ago
        There is no need for trolling. He's talking about encryption, but calls it security, that's something I have a problem with.
        bulatb 7y ago
        I meant the second paragraph about security in general, not TLS [0] encryption, but I can see how that's not clear. HTTPS improves security in part through encryption. [0] What do you think of that S?
    - bulatb 7y ago
      That's a good point and a dirty trick, but like you said, it's why we have HSTS and preload lists. I only serve HTTPS (as best I can) because I've never had a case where something truly justified the possibility my system would betray my user. I'm sure I could contrive one, and probably there's someone somewhere who'd agree, but I would rather treat that case existing as a bug to be fixed and not a use case to support. Otherwise you get stuff like the other recent thread [0] with people proudly serving unauthenticated binaries with HTTP for no defensible reason. Someone in a cousin comment made another, maybe better point: URLs get linked and crawled and cached and having them HTTP just normalizes something that was fine in 1995 but isn't fine in 2020. It's always possible for someone to get proxied like you said, but it's still safer overall if ever seeing "http://" http://" raises eyebrows. There's another front page thread [1] right now about the normalization of deviance. [0] https://news.ycombinator.com/item?id=22136710 https://news.ycombinator.com/item?id=22136710 [1] https://news.ycombinator.com/item?id=22144330 https://news.ycombinator.com/item?id=22144330
- captncraig 7y ago
  That makes sense. I wonder if any web servers have smarter decision making for that. Like give a hard 301 to modern browsers, but let older or nonstandard clients get a standard http response.
  - CydeWeys 7y ago
    There are so few browsers that don't support HTTPS that it's not worth worrying about it. Besides, if the security negotiation is to be done in plaintext, then it's trivial for an attacker to MITM a connection, replace the User-Agent headers, and then trick a server into thinking it should serve content insecurely. This is a huge gaping attack vector. It's better to just always serve securely.
- jwatt 7y ago
  FWIW, one issue with having the plain HTTP site available is that browsers (without the HTTPS Everywhere extension installed) will default to loading the unencrypted site when someone types your domain into their browser. Google is also giving plain HTTP links to your site when it turns up in results it seems.
- CydeWeys 7y ago
  To what end though? Why do you even need to support the insecure protocol? I'm not aware of any widely used browsers that can't do HTTPS. If that's what you're worried about, then you should HSTS preload all of your domains, so that browsers that do support HTTPS will only ever get the HTTPS version, and aren't susceptible to an SSLstrip attack.
  - superkuh 7y ago
    It's not an insecure protocol. What is insecure, in every single example I've seen in this thread and in the article, is the bad defaults of browsers executing javascript automatically. Without that terrible design choice, prioritized because of commerce and the desire to change the web of documents into a surveillance operating system, HTTP would be, and is, just fine. Anyway, to directly answer your question there are browsers that can't do all of HTTPS because of false "security" enhancements being pushed for sites that don't need it like restricting the set of TLS versions that are accepted. ref: https://scotthelme.co.uk/legacy-tls-is-on-the-way-out/ https://scotthelme.co.uk/legacy-tls-is-on-the-way-out/
    - wbl 7y ago
      Unless you think that someone changing the site to be a picture of a gaping hole is a problem.
    - pixl97 7y ago
      It is an insecure protocol. For example I was reading Hacker News over HTTP and there is this guy named superkuh saying "Hitler was right". See, with no execution of code one can completely change a message with no authentication.
    - wlll 7y ago
      > It's not an insecure protocol. What is insecure, in every single example I've seen in this thread and in the article, is the bad defaults of browsers executing javascript automatically. Without that terrible design choice, prioritized because of commerce and the desire to change the web of documents into a surveillance operating system, HTTP would be, and is, just fine. OK, so what you're saying here is that HTTP is insecure as long as the browser distributors continue to do something that (you say) is insecure. Well, I've got news for you. The browser distributors are going to continue to do this. Also, do you really think it's within reason to expect users to examine all the Javascript that is loaded on a page looking for malicious code before clicking some sort of button to run it?
- dane-pgp 7y ago
  For the few use cases where the dangers of HTTP can be reasonably consented to by the user, it would make sense to serve the content on a specific subdomain such as: http://insecure.example.com http://insecure.example.com alongside: https://www.example.com https://www.example.com
jwatt 7y ago
Exactly. As a user I've installed the browser add-on Let's Encript and have the "Encrypt All Sites Eligible" option enabled to block all unencrypted pages. On the odd occassion that I encounter a page that isn't available over HTTPS I'm prompted to choose whether I want to make an exception and allow the site to load for that session. I rarely do though.

superkuh 7y ago

Did you not read my comment? I love HTTPs. I make sure all my websites have it available. But I also make sure there's an HTTP site too.

bulatb 7y ago
Offering HTTP allows MITM attackers to strip HTTPS from visitors who want it. HSTS can help, but the vector still exists. Optional security is not just an upgrade; it opens up a downgrade path from more secure to less.
- zzzcpan 7y ago
  You can't securely disable http on websites, even if you are not offering it, because it still can be faked by a MITM attacker via proxying it to https. So removing http is pointless for security and only hurts legitimate uses. I guess this is also one of the reasons why "HSTS preload" exists. Also encryption is neither security nor privacy.
  - pixl97 7y ago
    Pray tell, how did you come to the conclusion that encryption is not security or privacy, and are you an Australian politician?
    - zzzcpan 7y ago
      There is no need for trolling. He's talking about encryption, but calls it security, that's something I have a problem with.
      - bulatb 7y ago
        I meant the second paragraph about security in general, not TLS [0] encryption, but I can see how that's not clear. HTTPS improves security in part through encryption. [0] What do you think of that S?
  - bulatb 7y ago
    That's a good point and a dirty trick, but like you said, it's why we have HSTS and preload lists. I only serve HTTPS (as best I can) because I've never had a case where something truly justified the possibility my system would betray my user. I'm sure I could contrive one, and probably there's someone somewhere who'd agree, but I would rather treat that case existing as a bug to be fixed and not a use case to support. Otherwise you get stuff like the other recent thread [0] with people proudly serving unauthenticated binaries with HTTP for no defensible reason. Someone in a cousin comment made another, maybe better point: URLs get linked and crawled and cached and having them HTTP just normalizes something that was fine in 1995 but isn't fine in 2020. It's always possible for someone to get proxied like you said, but it's still safer overall if ever seeing "http://" http://" raises eyebrows. There's another front page thread [1] right now about the normalization of deviance. [0] https://news.ycombinator.com/item?id=22136710 https://news.ycombinator.com/item?id=22136710 [1] https://news.ycombinator.com/item?id=22144330 https://news.ycombinator.com/item?id=22144330
captncraig 7y ago
That makes sense. I wonder if any web servers have smarter decision making for that. Like give a hard 301 to modern browsers, but let older or nonstandard clients get a standard http response.
- CydeWeys 7y ago
  There are so few browsers that don't support HTTPS that it's not worth worrying about it. Besides, if the security negotiation is to be done in plaintext, then it's trivial for an attacker to MITM a connection, replace the User-Agent headers, and then trick a server into thinking it should serve content insecurely. This is a huge gaping attack vector. It's better to just always serve securely.
jwatt 7y ago
FWIW, one issue with having the plain HTTP site available is that browsers (without the HTTPS Everywhere extension installed) will default to loading the unencrypted site when someone types your domain into their browser. Google is also giving plain HTTP links to your site when it turns up in results it seems.
CydeWeys 7y ago
To what end though? Why do you even need to support the insecure protocol? I'm not aware of any widely used browsers that can't do HTTPS. If that's what you're worried about, then you should HSTS preload all of your domains, so that browsers that do support HTTPS will only ever get the HTTPS version, and aren't susceptible to an SSLstrip attack.
- superkuh 7y ago
  It's not an insecure protocol. What is insecure, in every single example I've seen in this thread and in the article, is the bad defaults of browsers executing javascript automatically. Without that terrible design choice, prioritized because of commerce and the desire to change the web of documents into a surveillance operating system, HTTP would be, and is, just fine. Anyway, to directly answer your question there are browsers that can't do all of HTTPS because of false "security" enhancements being pushed for sites that don't need it like restricting the set of TLS versions that are accepted. ref: https://scotthelme.co.uk/legacy-tls-is-on-the-way-out/ https://scotthelme.co.uk/legacy-tls-is-on-the-way-out/
  - wbl 7y ago
    Unless you think that someone changing the site to be a picture of a gaping hole is a problem.
  - pixl97 7y ago
    It is an insecure protocol. For example I was reading Hacker News over HTTP and there is this guy named superkuh saying "Hitler was right". See, with no execution of code one can completely change a message with no authentication.
  - wlll 7y ago
    > It's not an insecure protocol. What is insecure, in every single example I've seen in this thread and in the article, is the bad defaults of browsers executing javascript automatically. Without that terrible design choice, prioritized because of commerce and the desire to change the web of documents into a surveillance operating system, HTTP would be, and is, just fine. OK, so what you're saying here is that HTTP is insecure as long as the browser distributors continue to do something that (you say) is insecure. Well, I've got news for you. The browser distributors are going to continue to do this. Also, do you really think it's within reason to expect users to examine all the Javascript that is loaded on a page looking for malicious code before clicking some sort of button to run it?
dane-pgp 7y ago
For the few use cases where the dangers of HTTP can be reasonably consented to by the user, it would make sense to serve the content on a specific subdomain such as: http://insecure.example.com http://insecure.example.com alongside: https://www.example.com https://www.example.com

jwatt 7y ago

Exactly. As a user I've installed the browser add-on Let's Encript and have the "Encrypt All Sites Eligible" option enabled to block all unencrypted pages. On the odd occassion that I encounter a page that isn't available over HTTPS I'm prompted to choose whether I want to make an exception and allow the site to load for that session. I rarely do though.