11 ms·

I am running an HTTP-only blog and it's getting harder every year not to switch to HTTPS. For instance, Whatsapp can not open HTTP links anymore.

projektfu 1y ago
You can proxy it, which for a small server might be the best way to avoid heavy traffic, through caching at the proxy.
g-b-r 1y ago
For god's sake, however complex ACME might be it's better than not supporting TLS
- sam_lowry_ 1y ago
  Why? The days of MITM boxes injecting content into HTTP traffic are basically over, and frankly they never were a thing in my part of the world. I see no other reason to serve content over HTTPS.
  - JoshTriplett 1y ago
    > Why? The days of MITM boxes injecting content into HTTP traffic are basically over The reason you don't see many MITM boxes injecting content into HTTP anymore is because of widespread HTTPS adoption and browsers taking steps to distrust HTTP, making MITM injection a near-useless tactic. (This rhymes with the observation that some people now perceive Y2K as overhyped fear-mongering that amounted to nothing, without understanding that immense work happened behind the scenes to avert problems.)
    - sam_lowry_ 1y ago
      How do browsers distrust HTTP, exactly?
      - castillar76 1y ago
        They’ve been making it harder and harder to serve things over HTTP-only for a while now. Steps like marking HTTP with big “NOT SECURE” labels and trying to auto-push to HTTP have been pretty effective. (With the exception of certain contexts, I think this is a generally good trend, FWIW.)
        g-b-r 1y ago
        I have to change two settings to be able to see plain http things, and luckily I only need to a handful of times a year. If I'm really curious about your plain http site I'll check it out through archive.org, and I'm definitely not going to keep visiting it frequently. It's been easy to live with forced https for at least five years (and for at least the last ten with https first, with confirmations for plain http).
        castillar76 1y ago
        I was genuinely taken aback by visiting a restaurant website last night that was only served over HTTP. (Attempting to hit it with HTTPS generated a cert error because their shared provider didn't have a cert for it.) These days, I'd gotten so used to things just being over HTTPS all the time that the warnings in the browser _actually worked_ to grab my attention. It's a restaurant that's been here with the same menu since the 1970s, and their website does absolutely nothing besides pass out information (phone number, menu, directions), so they probably put it up in 2002 and haven't changed it since. It was just a startling reminder of how ubiquitous HTTPS has gotten.
      - JoshTriplett 1y ago
        They show any site served over HTTP as explicitly not secure in the address bar (making HTTPS the "default" and HTTP the visibly dangerous option), they limit many web APIs to sites served over HTTPS ( https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts https://developer.mozilla.org/en-US/docs/Web/Security/Secure...) , https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts https://developer.mozilla.org/en-US/docs/Web/Security/Secure... ), they block or upgrade mixed-content by default (HTTPS sites cannot request HTTP-only resources anymore), they require HTTPS for HTTP/2 and HTTP/3, they increasingly attempt HTTPS to a site first even if linked/typed as http, they warn about downloads over http, and they're continuing to ratchet up such measures over time.
    - schoen 1y ago
      https://en.wikipedia.org/wiki/Preparedness_paradox https://en.wikipedia.org/wiki/Preparedness_paradox
      - JoshTriplett 1y ago
        Thank you!
  - DonHopkins 1y ago
    [flagged]
  - g-b-r 1y ago
    You see no reason for privacy, ok
- bigstrat2003 1y ago
  There's no good reason to serve a blog over TLS. You're not handling sensitive data, so unencrypted is just fine.
  - cAtte_ 1y ago
    relevant blog post and HN discussion: https://news.ycombinator.com/item?id=22146291 https://news.ycombinator.com/item?id=22146291
  - deleted 1y ago
    [deleted]
  - foobiekr 1y ago
    The reason is to prevent your site from becoming a watering hole where malicious actors use it to inject malware into the browsers of your users. TLS isn't for you, it's for your readers.
    - GoblinSlayer 1y ago
      Ads will inject it anyway.
      - nssnsjsjsjs 1y ago
        If there are ads.
    - dijit 1y ago
      but like, who’s doing that? Maybe the answer is disabling the JS runtime on non-TLS sites, maybe that has the added benefit of making the web (documents and “posters”) light again. SMS is unencrypted, phone calls are unencrypted- yet we don’t worry nearly as much about people injecting content or modifying things. Because we trust out providers, largely, but the capability 100% exists for that; with no actual recourse. With browsing the internet we do have recourse- optionally use a VPN. All of this security theatre is just moving the trust around, I would much rather make laws that protect the integrity of traffic sent via ISPs than add to the computational waste from military grade encrypting the local menu for the pizza shop. Worse still, the pizza shop won’t go through the effort so they either won’t bother having a website or will put it on facebook or some other crazy centralised platform. I’ll tell you something, I trust my ISP (Bahnhof- famous for protecting thepiratebay) a lot more than I trust Facebook not to do weird moderation activities.
- agarren 1y ago
  Why? I can understand the argument that you don’t want an ISP or a middlebox injecting ads or scripts (valid I think even if I’ve never encountered it to my knowledge), but otherwise you’re publishing content intended for the world. There’s presumably nothing especially sensitive that you need to hide on the wire.
  - mort96 1y ago
    > (valid I think even if I’ve never encountered it to my knowledge) Visitors to your website may encounter it. Do you not care that your visitors may be seeing ads? You're also leaking what your visitors are reading to their ISPs and governments. Maybe you don't consider anything you write about to be remotely sensitive, but how critically do you examine that with every new piece you write? If you wrote something which could be sensitive to readers in some parts of the world (something about circumventing censorship, something critical of some religion, something involving abortion or other forms of healthcare that some governments are cracking down on), do you then add SSL at that point? Or do you refrain from publishing it? Personally, I like the freedom to just not think about these things. I can write about whatever I want, however controversial it might be in some regions, no matter how dangerous it is for some people to be found reading about it, and be confident that my readers can expect at least a baseline of safety because my blog, like pretty much every other in the world today, uses cryptography to ensure that governments and ISPs can't use deep packet inspection to scan the words they read or use MITM to inject things into my blog. Does it really matter? Well probably not for my site specifically, but across all the blogs and websites in the world and all the visitors in the world, that's a whole lot of "probably not"s which all combine together into a huge "almost definitely".
    - nssnsjsjsjs 1y ago
      I agree but SSL doesn't encrypt the IP so there is that information leaked. That isn't to say don't use SSL but more it isn't 100% privacy protection from middlemen.
      - mort96 1y ago
pornel 1y ago
You're making a mistake assuming that the push for HTTPS-only Web is about protecting the content of your site. The problem is that mere existence of HTTP is a vulnerability. Users following any insecure link to anywhere allow MITM attackers to inject any content, and redirect to any URL. These can be targeted attacks against vulnerabilities in the browser. These can be turning browsers into a botnet like the Great Cannon. These can be redirects, popunders, or other sneaky tab manipulation for opening phishing pages for other domains (unrelated to yours) that do have important content. Your server probably won't even be contacted during such attack. Insecure URLs to your site are the vulnerability. Don't spread URLs that disable network-level security.

projektfu 1y ago

You can proxy it, which for a small server might be the best way to avoid heavy traffic, through caching at the proxy.

g-b-r 1y ago

For god's sake, however complex ACME might be it's better than not supporting TLS

sam_lowry_ 1y ago
Why? The days of MITM boxes injecting content into HTTP traffic are basically over, and frankly they never were a thing in my part of the world. I see no other reason to serve content over HTTPS.
- JoshTriplett 1y ago
  > Why? The days of MITM boxes injecting content into HTTP traffic are basically over The reason you don't see many MITM boxes injecting content into HTTP anymore is because of widespread HTTPS adoption and browsers taking steps to distrust HTTP, making MITM injection a near-useless tactic. (This rhymes with the observation that some people now perceive Y2K as overhyped fear-mongering that amounted to nothing, without understanding that immense work happened behind the scenes to avert problems.)
  - sam_lowry_ 1y ago
    How do browsers distrust HTTP, exactly?
    - castillar76 1y ago
      They’ve been making it harder and harder to serve things over HTTP-only for a while now. Steps like marking HTTP with big “NOT SECURE” labels and trying to auto-push to HTTP have been pretty effective. (With the exception of certain contexts, I think this is a generally good trend, FWIW.)
      - g-b-r 1y ago
        I have to change two settings to be able to see plain http things, and luckily I only need to a handful of times a year. If I'm really curious about your plain http site I'll check it out through archive.org, and I'm definitely not going to keep visiting it frequently. It's been easy to live with forced https for at least five years (and for at least the last ten with https first, with confirmations for plain http).
        castillar76 1y ago
        I was genuinely taken aback by visiting a restaurant website last night that was only served over HTTP. (Attempting to hit it with HTTPS generated a cert error because their shared provider didn't have a cert for it.) These days, I'd gotten so used to things just being over HTTPS all the time that the warnings in the browser _actually worked_ to grab my attention. It's a restaurant that's been here with the same menu since the 1970s, and their website does absolutely nothing besides pass out information (phone number, menu, directions), so they probably put it up in 2002 and haven't changed it since. It was just a startling reminder of how ubiquitous HTTPS has gotten.
    - JoshTriplett 1y ago
      They show any site served over HTTP as explicitly not secure in the address bar (making HTTPS the "default" and HTTP the visibly dangerous option), they limit many web APIs to sites served over HTTPS ( https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts https://developer.mozilla.org/en-US/docs/Web/Security/Secure...) , https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts https://developer.mozilla.org/en-US/docs/Web/Security/Secure... ), they block or upgrade mixed-content by default (HTTPS sites cannot request HTTP-only resources anymore), they require HTTPS for HTTP/2 and HTTP/3, they increasingly attempt HTTPS to a site first even if linked/typed as http, they warn about downloads over http, and they're continuing to ratchet up such measures over time.
  - schoen 1y ago
    https://en.wikipedia.org/wiki/Preparedness_paradox https://en.wikipedia.org/wiki/Preparedness_paradox
    - JoshTriplett 1y ago
      Thank you!
- DonHopkins 1y ago
  [flagged]
- g-b-r 1y ago
  You see no reason for privacy, ok
bigstrat2003 1y ago
There's no good reason to serve a blog over TLS. You're not handling sensitive data, so unencrypted is just fine.
- cAtte_ 1y ago
  relevant blog post and HN discussion: https://news.ycombinator.com/item?id=22146291 https://news.ycombinator.com/item?id=22146291
- deleted 1y ago
  [deleted]
- foobiekr 1y ago
  The reason is to prevent your site from becoming a watering hole where malicious actors use it to inject malware into the browsers of your users. TLS isn't for you, it's for your readers.
  - GoblinSlayer 1y ago
    Ads will inject it anyway.
    - nssnsjsjsjs 1y ago
      If there are ads.
  - dijit 1y ago
    but like, who’s doing that? Maybe the answer is disabling the JS runtime on non-TLS sites, maybe that has the added benefit of making the web (documents and “posters”) light again. SMS is unencrypted, phone calls are unencrypted- yet we don’t worry nearly as much about people injecting content or modifying things. Because we trust out providers, largely, but the capability 100% exists for that; with no actual recourse. With browsing the internet we do have recourse- optionally use a VPN. All of this security theatre is just moving the trust around, I would much rather make laws that protect the integrity of traffic sent via ISPs than add to the computational waste from military grade encrypting the local menu for the pizza shop. Worse still, the pizza shop won’t go through the effort so they either won’t bother having a website or will put it on facebook or some other crazy centralised platform. I’ll tell you something, I trust my ISP (Bahnhof- famous for protecting thepiratebay) a lot more than I trust Facebook not to do weird moderation activities.
agarren 1y ago
Why? I can understand the argument that you don’t want an ISP or a middlebox injecting ads or scripts (valid I think even if I’ve never encountered it to my knowledge), but otherwise you’re publishing content intended for the world. There’s presumably nothing especially sensitive that you need to hide on the wire.
- mort96 1y ago
  > (valid I think even if I’ve never encountered it to my knowledge) Visitors to your website may encounter it. Do you not care that your visitors may be seeing ads? You're also leaking what your visitors are reading to their ISPs and governments. Maybe you don't consider anything you write about to be remotely sensitive, but how critically do you examine that with every new piece you write? If you wrote something which could be sensitive to readers in some parts of the world (something about circumventing censorship, something critical of some religion, something involving abortion or other forms of healthcare that some governments are cracking down on), do you then add SSL at that point? Or do you refrain from publishing it? Personally, I like the freedom to just not think about these things. I can write about whatever I want, however controversial it might be in some regions, no matter how dangerous it is for some people to be found reading about it, and be confident that my readers can expect at least a baseline of safety because my blog, like pretty much every other in the world today, uses cryptography to ensure that governments and ISPs can't use deep packet inspection to scan the words they read or use MITM to inject things into my blog. Does it really matter? Well probably not for my site specifically, but across all the blogs and websites in the world and all the visitors in the world, that's a whole lot of "probably not"s which all combine together into a huge "almost definitely".
  - nssnsjsjsjs 1y ago
    I agree but SSL doesn't encrypt the IP so there is that information leaked. That isn't to say don't use SSL but more it isn't 100% privacy protection from middlemen.
    - mort96 1y ago

pornel 1y ago

You're making a mistake assuming that the push for HTTPS-only Web is about protecting the content of your site. The problem is that mere existence of HTTP is a vulnerability. Users following any insecure link to anywhere allow MITM attackers to inject any content, and redirect to any URL. These can be targeted attacks against vulnerabilities in the browser. These can be turning browsers into a botnet like the Great Cannon. These can be redirects, popunders, or other sneaky tab manipulation for opening phishing pages for other domains (unrelated to yours) that do have important content. Your server probably won't even be contacted during such attack. Insecure URLs to your site are the vulnerability. Don't spread URLs that disable network-level security.