10 ms·

The worst web browser I have access to is the "experimental" one on a Kindle 4. Most web pages that one might want to visit will not load in this web browser—be

The worst web browser I have access to is the "experimental" one on a Kindle 4. Most web pages that one might want to visit will not load in this web browser—because it does not support modern versions of TLS. For the reasons mentioned in this article—it's probably a good idea to keep plain HTTP access available on your websites.

forgotmypw17 6y ago
This, a thousand times. No one is going to mitm someone browsing my text blog. On the other hand, https creates many barriers to access, including recent version requirement, time sync, and extra cpu and bandwidth.
- tpxl 6y ago
  ISPs regularly MITM http websites to inject ads (in the US even).
  - forgotmypw17 6y ago
    It happens. I think I'd rather my site be served with ads, than not at all. It would be great if we could always automatically choose the right option, but browsers don't do that.
    - tpxl 6y ago
      Ads aren't that much of a problem, but serving cryptominers/phishing websites/viruses is a real issue.
      - forgotmypw17 6y ago
        Do ISPs really do that?
        tpxl 6y ago
        I haven't heard of it, but other malicious actors surely do.
- cutler 6y ago
  Not to mention single points of failure like Letsencrypt.
kstrauser 6y ago
Eh, 98.24% of all users worldwide can use TLS 1.2: https://caniuse.com/?search=tls%201.2 https://caniuse.com/?search=tls%201.2 I'm not willing to make security exceptions to support devices from 2011. "HTTPS by default" lifts all boats: people who would MITM your users can't tell if they're reading your nice blog or a critique of their local government, and that's a good thing.
- SulfurHexaFluri 6y ago
  With DNS over HTTPS and encrypted SNI, soon the only information you will get is "They accessed a website on amazon/cloudflair"
  - _-david-_ 6y ago
    This is not a guarantee. If you have your own public IP it is quite possible to do a reverse ip lookup and get the domain.
- exporectomy 6y ago
  They can tell what page you're looking at from the host name and request response lengths, though, right? Especially if those are the only two pages on your site.
- sundarurfriend 6y ago
  > Eh, 98.24% of all users worldwide can use TLS 1.2: https://caniuse.com/?search=tls%201.2 https://caniuse.com/?search=tls%201.2 That's 98.24% of users captured by CanIUse's sources (which seems to be StatCounter). Like most things on the Internet, that's a bubble - the bubble of users who visit statcounter-infested websites, and are able to run their scripts. And the point of the original post is to think outside the bubble. Not in all cases - if you're a B2B service, or selling T-shirts with slogans on them, CanIUse is likely a good enough source to base your choices on. But if you're a government website, or providing critical Covid-19 data for example, it's irresponsible to ignore these long-tail of users who fall outside expected and easily visible patterns. There's a spectrum between these two kinds of websites, and it's worth thinking about where you fall on that and how many you're comfortable with denying access to your website. It's a tradeoff between security and accessibility, and we should at least be thoughtful about the implications of our decisions.
chrismorgan 6y ago
The trouble is that you can’t support HTTP without completely undermining HTTPS. If you support HTTP at all, you’re damaging the experience for the almost everyone that could have used HTTPS: almost no one will get the HTTPS version unless you deliberately push them over to it, which you will only be able to do after page load by some JavaScript-based user-agent or feature-based sniffing, so now the page loads and then reloads immediately, every time the user visits your site by URL, and you’re causing trouble with search engines, and it’s a regular maintenance burden because no one treads this path so you’ll have to figure out the cut-off points yourself as certificates change, and on top of that it’ll always be subject to a downgrade attack, so now you can’t ever depend on HTTPS. Remember also that various new features are gated on using a secure context (which roughly means “HTTPS”), like HTTP/2 and HTTP/3. And as for entering passwords or the likes, you’d be opening quite a can of worms if you allow that over cleartext HTTP. So… yeah, it sounds nice in theory, but I think that it’s just not practical or advisable to retain plain HTTP support. Even supporting TLS < 1.2 or older cipher suites is steadily becoming inadvisable, only to be used on a few sorts of websites. The unfortunate fact of the matter is that you can’t support ancient devices without harming things materially for everything else.
- wizzwizz4 6y ago
  You can: have an “insecure.” version of your site, like people used to have a “secure.” version.
  - chrismorgan 6y ago
    You can’t: ① If it’s on the same domain, it would necessitate weakening the HSTS policy, removing includeSubDomains and preload. ② If it’s on a separate domain, you’re actively training people to do dangerous things and get phished. ③ Pretty much the only way this will ever be used is if you push people to it and ensure that search engines choose it rather than the secure version. (Implicit in this is a significant SEO hassle.) Thus you’re back exactly where you started.
- superkuh 6y ago
  The implicit premise here is that your website requires HTTPS only and that a theoretical downgrade attack is enough to justify not having http at all. Most websites don't even need HTTPS and the complications and sacrifice of autonomy required isn't worth it. Remember, there are no cert authorities that are human people. They are all corporations or institutions. Having to get an incorporated entity's permission to communicate will have dangerous consequences eventually. HTTPS everywhere is done with the best of intentions but it will be the centralizing push that provides juicy targets for government and corporate censorship.

forgotmypw17 6y ago

This, a thousand times. No one is going to mitm someone browsing my text blog. On the other hand, https creates many barriers to access, including recent version requirement, time sync, and extra cpu and bandwidth.

tpxl 6y ago
ISPs regularly MITM http websites to inject ads (in the US even).
- forgotmypw17 6y ago
  It happens. I think I'd rather my site be served with ads, than not at all. It would be great if we could always automatically choose the right option, but browsers don't do that.
  - tpxl 6y ago
    Ads aren't that much of a problem, but serving cryptominers/phishing websites/viruses is a real issue.
    - forgotmypw17 6y ago
      Do ISPs really do that?
      - tpxl 6y ago
        I haven't heard of it, but other malicious actors surely do.
cutler 6y ago
Not to mention single points of failure like Letsencrypt.

kstrauser 6y ago

Eh, 98.24% of all users worldwide can use TLS 1.2: https://caniuse.com/?search=tls%201.2 https://caniuse.com/?search=tls%201.2 I'm not willing to make security exceptions to support devices from 2011. "HTTPS by default" lifts all boats: people who would MITM your users can't tell if they're reading your nice blog or a critique of their local government, and that's a good thing.

SulfurHexaFluri 6y ago
With DNS over HTTPS and encrypted SNI, soon the only information you will get is "They accessed a website on amazon/cloudflair"
- _-david-_ 6y ago
  This is not a guarantee. If you have your own public IP it is quite possible to do a reverse ip lookup and get the domain.
exporectomy 6y ago
They can tell what page you're looking at from the host name and request response lengths, though, right? Especially if those are the only two pages on your site.
sundarurfriend 6y ago
> Eh, 98.24% of all users worldwide can use TLS 1.2: https://caniuse.com/?search=tls%201.2 https://caniuse.com/?search=tls%201.2 That's 98.24% of users captured by CanIUse's sources (which seems to be StatCounter). Like most things on the Internet, that's a bubble - the bubble of users who visit statcounter-infested websites, and are able to run their scripts. And the point of the original post is to think outside the bubble. Not in all cases - if you're a B2B service, or selling T-shirts with slogans on them, CanIUse is likely a good enough source to base your choices on. But if you're a government website, or providing critical Covid-19 data for example, it's irresponsible to ignore these long-tail of users who fall outside expected and easily visible patterns. There's a spectrum between these two kinds of websites, and it's worth thinking about where you fall on that and how many you're comfortable with denying access to your website. It's a tradeoff between security and accessibility, and we should at least be thoughtful about the implications of our decisions.

chrismorgan 6y ago

The trouble is that you can’t support HTTP without completely undermining HTTPS. If you support HTTP at all, you’re damaging the experience for the almost everyone that could have used HTTPS: almost no one will get the HTTPS version unless you deliberately push them over to it, which you will only be able to do after page load by some JavaScript-based user-agent or feature-based sniffing, so now the page loads and then reloads immediately, every time the user visits your site by URL, and you’re causing trouble with search engines, and it’s a regular maintenance burden because no one treads this path so you’ll have to figure out the cut-off points yourself as certificates change, and on top of that it’ll always be subject to a downgrade attack, so now you can’t ever depend on HTTPS. Remember also that various new features are gated on using a secure context (which roughly means “HTTPS”), like HTTP/2 and HTTP/3. And as for entering passwords or the likes, you’d be opening quite a can of worms if you allow that over cleartext HTTP. So… yeah, it sounds nice in theory, but I think that it’s just not practical or advisable to retain plain HTTP support. Even supporting TLS < 1.2 or older cipher suites is steadily becoming inadvisable, only to be used on a few sorts of websites. The unfortunate fact of the matter is that you can’t support ancient devices without harming things materially for everything else.

wizzwizz4 6y ago
You can: have an “insecure.” version of your site, like people used to have a “secure.” version.
- chrismorgan 6y ago
  You can’t: ① If it’s on the same domain, it would necessitate weakening the HSTS policy, removing includeSubDomains and preload. ② If it’s on a separate domain, you’re actively training people to do dangerous things and get phished. ③ Pretty much the only way this will ever be used is if you push people to it and ensure that search engines choose it rather than the secure version. (Implicit in this is a significant SEO hassle.) Thus you’re back exactly where you started.
superkuh 6y ago
The implicit premise here is that your website requires HTTPS only and that a theoretical downgrade attack is enough to justify not having http at all. Most websites don't even need HTTPS and the complications and sacrifice of autonomy required isn't worth it. Remember, there are no cert authorities that are human people. They are all corporations or institutions. Having to get an incorporated entity's permission to communicate will have dangerous consequences eventually. HTTPS everywhere is done with the best of intentions but it will be the centralizing push that provides juicy targets for government and corporate censorship.