I have had HTTPS-by-default for years and I can say that we're past the point where there's noticeable year-to-year change for which sites aren't HTTPS. It's almost always old stuff that pre-dates Let's Encrypt (and presumably just nobody ever added HTTPS). The news site which stopped updating in 2007, the blog somebody last posted to in 2011, that sort of thing.
I think it's important to emphasise that although Tim's toy hypermedia system (the "World Wide Web") didn't come with baked in security, ordinary users have never really understood that. It seems to them as though http://foo.example/ must be guaranteed to be foo.example, just making that true by upgrading to HTTPS is way easier than somehow teaching billions of people that it wasn't true and then what they ought to do about that.
I am reminded of the UK's APP scams. "Authorized Push Payment" was a situation where ordinary people think they're paying say, "Big Law Firm" but actually a scammer persuaded them to give money to an account they control because historically the UK's payment systems didn't care about names, so to it a payment to "Big Law Firm" acct #123456789 is the same as a payment to "Jane Smith" acct #123456789 even though you'd never get a bank to open you an account in the name of "Big Law Firm" without documents the scammer doesn't have. To fix this, today's UK payment systems treat the name as a required match not merely for your records, so when you say "Big Law Firm" and try to pay Jane's account because you've been scammed, the software says "Wrong, are you being defrauded?" and so you're safe 'cos you have no reason to fill out "Jane Smith" as that's not who you're intending to give money to.
We could have tried to teach all the tens of millions of UK residents that the name was ignored and so they need other safeguards, but that's not practical. Upgrading payment systems to check the name was difficult but possible.
While Google and friends are happy to push for https, it’s dramatically easier to scam people via ads or AI generated content. Claiming plain HTTP is scary seems like a straw man tbh
The threat model of HTTP isn't site owners, it's that anyone else can change the content and you can't tell that it didn't come from the original site.
It's not a strawman, it's a real attack that we've seen for decades.
The entire guidance of "don't connect to an open wireless AP"? That's because a malicious actor who controlled the AP could read and modify your HTTP traffic - inject ads, read your passwords, update the account number you requested your money be transferred to. The vast majority of that threat is gone if you're using HTTPS instead of HTTP.
Then perhaps the problem is open APs? There are still legitimate uses for HTTP including reading static content.
Say we all move to HTTPS but then let’s encrypt goes away, certificate authority corps merge, and then google decides they also want remote attestation for two way trust or whatever - the whole world becomes walled up into an iOS situation. Even a good idea is potentially very bad at the hands of unregulated corps (and this is not a hypothetical)
Onion websites also don't need TLS (they have their own built-in encryption) so that solves the previous commenter's complaint too. Add in decentralized mesh networking and it might actually be possible to eliminate the dependency on an ISP too.
CAs are uniquely assertive about their right to cut off your access.
My hosting provider may accidentally fuck up, but they'll apologise and fix it.
My CA fucks up, they e-mail me at 7pm telling me I've got to fix their fuck-up for them by jumping through a bunch of hoops they have erected, and they'll only give me 16 hours to do it.
Of course, you might argue my hosting provider has a much higher chance of fucking up....
They're focused on the thing that'll get the most people up and running for the least extra work from them. When you say "push" do you just mean that's the default or are they trying to get you to not use another ACME client like acme.sh or one built in to servers you run anyway or indeed rolling your own?
Like, the default for cars almost everywhere is you buy one made by some car manufacturer like Ford or Toyota or somebody, but usually making your own car is legal, it's just annoyingly difficult and so you don't do that.
As a car mechanic, you could at least tune... until these days when tou can realistically tune only 10..15 years old models, because newer ones are just locked down computers on wheels.
It's actually not that bad in most states, some even have exceptions to emissions requirements for certain classes of self-built cars.
Now, getting required insurance coverage, that can be a different story. Btu even there, many states allow you to post a bond in lieu of an insurance policy meeting state minimums.
ISRG (Let's Encrypt's parent entity) wrote Certbot, initially under the name "letsencrypt" but it was quickly renamed to be less confusing, and re-homed to the EFF rather than ISRG itself.
So, what you've said is true today, but historically Certbot's origin is tied to Let's Encrypt, which makes sense because initially ACME isn't a standard protocol, it's designed to become a standard protocol but it is still under development and the only practical server implementations are both developed by ISRG / Let's Encrypt. RFC 8555 took years.
Yes, it started that way, but complaining about the current auto-update behavior of the software (not the ACME protocol), is completely unrelated to Let's Encrypt and is instead an arbitrary design decision by someone at EFF.
Do you depend on a DNS root server to map your website name to your IP address? That's a third party.
There are ways to remove that dependency, but it's going to involve a decentralized DNS replacement like Namecoin or Handshake, many of which include their own built-in alternatives to the CA system too so if "no third parties" is something you truly care about you can probably kill two birds with one stone here.
There are dozens of us I guess that care about this kind of thing. I have never really understood the obsession with https for static content that I don't care if anyone can see I am reading like a blog post. HTTPS should be for things that matter, everything else can, and think should use HTTP when it is not necessary.
Depending on yet another third party to provide what is IMHO a luxury should not be required, and I have been continually confused as to why it is being forced down everyone's throat.
It’s static while you control it. Soon as I MIIT your content it will look to your users like you updated your site with a crypto miner and a credit card form. You can publish your site with a self-signed key if you’d like and only depend on your ISP/web host provider, DNS provider, domain registrar, and the makers of your host OS and web server and a few dozen other things.
You just clearly don’t understand it is important that no one injects anything into your code while I am browsing it.
With http it is trivial.
So you say you don’t care if my ISP injects whole bunch of ads and I don’t even see your content but only the ads and I blame you for duping me into watching them.
Nowadays VPN providers are popular what if someone buys VPN service from the shitty ones and gets treated like I wrote above and it is your reputation of your blog devastated.
There are good arguments for it, but it's also not a coincidence that they happen to align with Google's business objectives. Ex it's hard to issue a TLS cert without notifying Google of it.
If that were the universal state, then it would be easy to tell when someone was visiting a site that mattered, and you could probably infer a lot about it by looking at the cleartext of the non-HTTPS side they were viewing right before they went to it.
You can already see what site someone visits with HTTPS. It's in the Client Hello, and is important for things like L4 load balancing (e.g. HAProxy can look at the host to choose what backend to forward the TCP packets for that connection to without terminating TLS). It's also important for network operators (e.g. you at home) to be able to filter unwanted traffic (e.g. Google's).
I don't think seeing the site is too important, although there are TLS extensions to encrypt that, too[0]. In practice, a huge chunk of sites still have unique IPs, so seeing that someone is connecting to 1.2.3.4 gives you a pretty good idea of what site they're visiting. That's even easier if they're using plaintext DNS (i.e. instead of DoH) so that you can correlate "dig -t a example.com => 1.2.3.4" followed immediately by a TCP connection to 1.2.3.4. CDNs like Cloudflare can mitigate that for a lot of sites, but not millions of others.
However, the page you're fetching from that domain is encrypted, and that's vastly more sensitive. It's no big deal to visit somemedicinewebsite.com in a theocratic region like Iran or Texas. It may be a very big deal to be caught visiting somemedicinewebsite.com/effective-abortion-meds/buy. TLS blocks that bit of information. Today, it still exposes that you're looking at plannedparenthood.com, until if/when TLS_ECH catches on and becomes pervasive. That's a bummer. But you still have plausible deniability to say "I was just looking at it so I could see how evil it was", rather than having to explain why you were checking out "/schedule-an-appointment".
Yes that's why I listed a couple reasons why adopting ECH everywhere is not straightforwardly all good. The network operator one in particular is I think quite important. It happens that the same company with the largest pushes for "privacy" (Google) has also been constantly making it more difficult to make traffic transparent to the actual device owner (e.g. making it so you can't just drop a CA onto your phone and have all apps trust it). Things like DoH, ECH, and ubiquitous TLS (with half the web making an opaque connection to the same Cloudflare IPs) then become weaponized against device owners.
AFAIK it's still not that widely adopted or can be easily blocked/disabled on a network though.
That sounds like an Android issue, not a TLS issue. If I need to break TLS I can add my own CA. Not having TLS is not the solution. Google will find other ways to take control from you.
Just because you don't care doesn't mean nobody cares. I don't want anyone snooping on what I browse regardless of how "safe" someone thinks it is.
My navigation habits are boring but they are mine, not anyone else's to see.
A server has no way to know whether the user cares or not, so they are not in a position to choose the user's privacy preferences.
Also: a page might be fully static, but I wouldn't want $GOVERNMENT or $ISP or $UNIVERSITY_IT_DEPARTMENT to inject propaganda, censor... Just because it's safe for you doesn't mean it's safe for everyone.
This is still not that common but I used to work on a commercial web proxy that did exactly this. The only way it works is if the company pushes out a new root certificate via group policy (or something similar) so that the proxy can re-encrypt the data. Users can tell that this is being done by examining the certificate.
But this is mostly a waste of time, these days companies just install agents on each laptop to monitor activity. If you do not own the machine/network you are using then don’t visit sites hat you don’t want them to see.
It doesn't MITM anything. Do you see that as normal? Because I don't. We're adults here and I'm a tech guy, there's zero reason to control anything in my laptop.
In fact it's just a regular laptop that I fully control and installed from scratch, straight out of Apple's store. As all my company laptops have been.
And if it was company policy I would refuse indeed. I would probably not work there in the first place, huge red flag. If I really had to work there for very pressing reasons I would do zero personal browsing (which I don't do anyways).
Not even when I was an intern at random corpo my laptop was MITMed.
Using an employer-issued computer for anything but work for that employer is foolish, for a multitude of legal and other reasons. Privacy is just one of them.
Agreed. I think that the push to make everything HTTPS is completely unnecessary, and in fact counterproductive to security. By throwing scary warnings in front of users when there is no actual security threat, we teach users that the scary warnings don't matter and they just should click past them. Warning when a site doesn't use TLS is a clear cut case of crying wolf.
Doesn't that mean that technically, any node in the network between you and your reader can mutate the contents of the blog in-transit without anyone being the wiser (up to and including arbitrary JavaScript inline injection)?
Devil's advocate, but maybe ISPs should all inject ads to make a point. They make money, and anyone using HTTP gets taught a free lesson on what MITM means
This puts the question into my brain, which I have never thought to pursue, of whether you could offer a self-signed cert that the user has to install for HTTPS.
Their client will complain loudly until and unless they install it, but then for those who care you could offer the best of both worlds.
Almost certainly more trouble than it's worth. G'ah, and me without any free time to pursue a weekend hobby project!
Mmmm, great that and mandatory key rotation every 90 days, plus needing to get a cert from an approved CA, means just that more busy work to have an independent web presence.
I don't like people externalizing their security policy preferences. Yes this might be more secure for a class of use-cases, but I as a user should be allowed to decide my threat model. It's not like these initiatives really solve the risks posed by bad actors. We have so much compliance theater around email, and we still have exactly the same threats and issues as existed twenty years ago.
I distinctly remember trying to sign up for Pandora’s premium plan back in 2012 and their credit card form being served and processed over HTTP. I emailed them telling them that I wanted to give them my money if they would just fix the form. They never got back to me or fix it for several more years while I gave my money to Spotify. Back then HTTPS was NOT the norm and it was a battle to switch people to it. Yes it is annoying for internal networks and a few other things but it is necessary.
In the early to mid 2000s I would believe this. But for a major e-commerce provider in 2012? That seems vanishing improbable.
PCI DSS is the data security standard required by credit card processors for you to be able to accept credit card payments online. Since version 1.0 came out in 2004, Requirement 4.1 has been there, requiring encrypted connections when transmitting card holder information.
There’s certainly was a time when you had two parts of a commerce website: one site all of the product stuff and catalogs and categories and descriptions which are all served over HTTP (www.shop.com) and then usually an entirely separate domain (secure.shop.com) where are the actual checkout process started that used SSL/TLS. This was due to the overhead of SSL in the early 2000s and the cost of certificates. This largely went away once Intel processors got hardware accelerated instructions for things like AES, certificates became more cost-effective, and then let’s encrypt made it simple.
Occasionally during the 2000s and 2010s you might see HTML form that were served over HTTP and the target was an HTTPS URL but even that was rare simply because it was a lot of work to make it that complex instead of having the checkout button just take you to an entirely different site
Doesn't it already do this? I keep a domain or two on HTTP to force network-level auth flows (which don't always fire correctly when hitting HTTPS) and I've gotten warnings from Chrome about those sites every time for years... Only if I've been to the site recently does the warning not show up.
Right now it only shows a little bubble in the URL bar saying "Not Secure", I think. (So, that is a "warning", in a sense.) TFA is saying there will now be an interstitial if you attempt an HTTP connection.
HSTS might also interact with this, but I'd expect an HSTS site to just cause Chrome to go for HTTPS (and then that connection would either succeed or fail).
> to force network-level auth flows (which don't always fire correctly when hitting HTTPS)
The whole point of HTTPS is basically that these shouldn't work, essentially. Vendors need to stop implementing weird network-level auths by MitM'ing the connection, and DHCP has an option to signal to someone joining a network that they need to go to a URL to do authentication. These MitM-ers are a scourge, and often cause a litany of poor behavior in applications…
Chrome has shown the HTTP warning in Incognito mode for about a year, and has shown the warning if you're in Advanced Protection mode for about 2-3 years.
> I used to test with http://neverssl.com/ until they added HTTPS for some reason.
My first reaction was along the lines of "What? That can't possibly be right..."
After testing a bit, it looks like you can load https://neverssl.com but it'll just redirect you to a non-https subdomain. OTOH, if the initial load before redirecting is HTTPS then it shouldn't work on hotel wifi or whatever, so still seems like it defeats the purpose.
neverssl added an HTTPS version for browsers that automatically connect to HTTPS when entering a domain name (like Chrome probably will after this change, eventually). The HTTPS version of the site uses Javascript to load a random http:// subdomain of neverssl.com so automatic HTTPS redirects are still defeated.
http.rip will probably show a "website unavailable" error at some point unless you manually type in the http:// prefix.
http://www.slackware.com/ is probably the biggest website I'm aware of that does not serve encrypted traffic[1]. but there are a few other legitimately useful resources that don't encrypt.
What's worse, many plaintext HTTP connections today are entirely invisible to users, as HTTP sites may immediately redirect to HTTPS sites. That gives users no opportunity to see Chrome's "Not Secure" URL bar warnings after the risk has occurred, and no opportunity to keep themselves safe in the first place.
Two hosting providers I use only offer HTTP redirects (one being so bad it serves up a self signed cert on the redirect if you attempt HTTPS) so hopefully this kicks them into gear to offer proper secure redirects.
Usually, completing the domain name by adding the final period will do the job. Instead of entering myprinter into the address bar, try myprinter. so your DNS server doesn't try to resolve myprinter, myprinter.domain, myprinter.domain.tld, and whatever other search domains have been configured. A real, fully-qualified domain ends in a period, though most tools will happily let you avoid that final period.
Alternatively, .local domains will work for mDNS-capable devices (and non-mDNS-capable devices if you like to risk things breaking randomly), and the .internal TLD has been reserved so .internal domains should also work for local addresses.
Anyone have a good recipe for setting up an HTTPS for one-off experiments in localhost? I generally don't because there isn't much of a compromise story there, but it's always been a security weakness in how I do tests and if Chrome is going to start reminding me stridently I should probably bother to fix it.
How exactly are unencrypted localhost connections a security weakness? To intercept the data on a loopback connection you'd need a level of access where encryption wouldn't really add much privacy.
They mention it later in the article; if they drop connections to internal networks from the graph, Linux shoots up all the way to 97%.
The answer is probably that people that run Linux are far more likely to run a homelab intranet that isn't secured by HTTPS, because internal IP addresses and hostnames are a hassle to get certificates for. (Not to mention that it's slightly pointless on most intranets to use HTTPS.)
> If you exclude navigations to private sites, then the distribution becomes much tighter across platforms. In particular, Linux jumps from 84% HTTPS to nearly 97% HTTPS when limiting the analysis to public sites only.
Sounds like it's just because a large chunk of Linux usage is for web interfaces on the local machine or network, rather than everyday web browsing.
Silly question and one I should probably already know the answer to but never really got around to thinking through: are there practical concerns for not doing TLS in your home intranet?
It means that if someone has patched into your local network they can access anything in there, but they have to get in first, right? So how concerned should one be in these scenarios
(a) one has wifi with WPA2 enabled
(b) there's a Verizon-style router to the outside world but everything is wired on the house side?
Main reason is that it's hard to get certificates for intranets that all devices will properly trust.
Public CAs don't issue (free) certificates for internal hostnames and running your own CA has the drawback that Android doesn't allow you to "properly" use a personal CA without root, splitting it's CA list between the automatically trusted system CA list and the per-application opt-in user CA list. (It ought to be noted that Apple's personal CA installation method uses MDM, which is treated like a system CA list). There's also random/weird one-offs like how Firefox doesn't respect the system certificate store, so you need to import your CA certificate separately in Firefox.
The only real option without running into all those problems is to get a regular (sub)domain name and issue certificates for that, but that usually isn't free or easy. Not to mention that if you do the SSL flow "properly", you need to issue one certificate for each device, which leaks your entire intranet to the certificate transparency log (this is the problem with Tailscale's MagicDNS as a solution). Alternatively you need to issue a wildcard certificate for your domains, but that means that every device in your intranet can have a valid SSL certificate for any other domain name on your certificate.
> You can get $2/yr domain names on weird TLDs like .site, .cam, .link, ...
You can, but as stated - that's not free (or easy). That's still yet another fee you have to pay for... which hurts adoption of HTTPS for intranets (not to mention it's not really an intranet if it's reliant on something entirely outside of that intranet.)
If LetsEncrypt charged 1$ to issue/renew a certificate, they wouldn't have made a dent in the public adoption of HTTPS certificates.
> Not necessarily, you don't route the domain externally, and use offline DNS challenge/request to renew the certificate.
I already mentioned that one, that's the wildcard method.
Perhaps you might worry about hostile IOT doodads snooping on things that arent their business or making insecure public webpages with UPNP. If it is just devices you truly control and you never expose an unhardened device, then a walled garden can be fine.
Also, if WPA2 ever becomes extremely broken. There was a period of 3-5 yrs where WEP was taking forever to die at the same time that https was taking forever to become commonplace and you could easily join networks and steal facebook credentials out of the air. If you lived in an apartment building and had an account get hacked between maybe 2008-2011, you were probably affected by this.
I have had HTTPS-by-default for years and I can say that we're past the point where there's noticeable year-to-year change for which sites aren't HTTPS. It's almost always old stuff that pre-dates Let's Encrypt (and presumably just nobody ever added HTTPS). The news site which stopped updating in 2007, the blog somebody last posted to in 2011, that sort of thing.
I think it's important to emphasise that although Tim's toy hypermedia system (the "World Wide Web") didn't come with baked in security, ordinary users have never really understood that. It seems to them as though http://foo.example/ must be guaranteed to be foo.example, just making that true by upgrading to HTTPS is way easier than somehow teaching billions of people that it wasn't true and then what they ought to do about that.
I am reminded of the UK's APP scams. "Authorized Push Payment" was a situation where ordinary people think they're paying say, "Big Law Firm" but actually a scammer persuaded them to give money to an account they control because historically the UK's payment systems didn't care about names, so to it a payment to "Big Law Firm" acct #123456789 is the same as a payment to "Jane Smith" acct #123456789 even though you'd never get a bank to open you an account in the name of "Big Law Firm" without documents the scammer doesn't have. To fix this, today's UK payment systems treat the name as a required match not merely for your records, so when you say "Big Law Firm" and try to pay Jane's account because you've been scammed, the software says "Wrong, are you being defrauded?" and so you're safe 'cos you have no reason to fill out "Jane Smith" as that's not who you're intending to give money to.
We could have tried to teach all the tens of millions of UK residents that the name was ignored and so they need other safeguards, but that's not practical. Upgrading payment systems to check the name was difficult but possible.
While Google and friends are happy to push for https, it’s dramatically easier to scam people via ads or AI generated content. Claiming plain HTTP is scary seems like a straw man tbh
The threat model of HTTP isn't site owners, it's that anyone else can change the content and you can't tell that it didn't come from the original site.
It's not a strawman, it's a real attack that we've seen for decades.
The entire guidance of "don't connect to an open wireless AP"? That's because a malicious actor who controlled the AP could read and modify your HTTP traffic - inject ads, read your passwords, update the account number you requested your money be transferred to. The vast majority of that threat is gone if you're using HTTPS instead of HTTP.
Then perhaps the problem is open APs? There are still legitimate uses for HTTP including reading static content.
Say we all move to HTTPS but then let’s encrypt goes away, certificate authority corps merge, and then google decides they also want remote attestation for two way trust or whatever - the whole world becomes walled up into an iOS situation. Even a good idea is potentially very bad at the hands of unregulated corps (and this is not a hypothetical)
I run my blog in unencrypted HTTP/1.1 just to make a point that we do not have to depend on third parties to publish content online.
And I noticed that Whatsapp is even worse than Chrome, it opens HTTPS even if I share HTTP links.
Depend on one less third party, you still depend on the DNS Root servers, your ISP / hosting, domain registry, etc.
Host an onion website at home using solar energy, and the only third party your website will depend on is your internet provider :)
Onion websites also don't need TLS (they have their own built-in encryption) so that solves the previous commenter's complaint too. Add in decentralized mesh networking and it might actually be possible to eliminate the dependency on an ISP too.
CAs are uniquely assertive about their right to cut off your access.
My hosting provider may accidentally fuck up, but they'll apologise and fix it.
My CA fucks up, they e-mail me at 7pm telling me I've got to fix their fuck-up for them by jumping through a bunch of hoops they have erected, and they'll only give me 16 hours to do it.
Of course, you might argue my hosting provider has a much higher chance of fucking up....
Let's Encrypt pushes me to run its self-updating certbot on my personal server, which is a big no-go.
I know about acme.sh, but still...
They're focused on the thing that'll get the most people up and running for the least extra work from them. When you say "push" do you just mean that's the default or are they trying to get you to not use another ACME client like acme.sh or one built in to servers you run anyway or indeed rolling your own?
Like, the default for cars almost everywhere is you buy one made by some car manufacturer like Ford or Toyota or somebody, but usually making your own car is legal, it's just annoyingly difficult and so you don't do that.
As a car mechanic, you could at least tune... until these days when tou can realistically tune only 10..15 years old models, because newer ones are just locked down computers on wheels.
>usually making your own car is legal
It may be legal but good luck ever getting registration for it.
It's actually not that bad in most states, some even have exceptions to emissions requirements for certain classes of self-built cars.
Now, getting required insurance coverage, that can be a different story. Btu even there, many states allow you to post a bond in lieu of an insurance policy meeting state minimums.
Let's Encrypt does not write or maintain certbot
ISRG (Let's Encrypt's parent entity) wrote Certbot, initially under the name "letsencrypt" but it was quickly renamed to be less confusing, and re-homed to the EFF rather than ISRG itself.
So, what you've said is true today, but historically Certbot's origin is tied to Let's Encrypt, which makes sense because initially ACME isn't a standard protocol, it's designed to become a standard protocol but it is still under development and the only practical server implementations are both developed by ISRG / Let's Encrypt. RFC 8555 took years.
Yes, it started that way, but complaining about the current auto-update behavior of the software (not the ACME protocol), is completely unrelated to Let's Encrypt and is instead an arbitrary design decision by someone at EFF.
I made this to redirect HTTPS to HTTP with whatsapp:
https://multiplayeronlinestandard.com/goto.html (the reason for the domain is I will never waste time on HTTPS but github does it automatically for free up to 100GB/month)
Do you depend on a DNS root server to map your website name to your IP address? That's a third party.
There are ways to remove that dependency, but it's going to involve a decentralized DNS replacement like Namecoin or Handshake, many of which include their own built-in alternatives to the CA system too so if "no third parties" is something you truly care about you can probably kill two birds with one stone here.
Registrar is the big one, if yours decides to do a Google and randomly ban you and automatically decline your appeal with AI, you're stuffed.
This is generally my biggest concern. Not that I'm doing anything shady, I've wanted to setup a potentially politically charged site in the past.
There are dozens of us I guess that care about this kind of thing. I have never really understood the obsession with https for static content that I don't care if anyone can see I am reading like a blog post. HTTPS should be for things that matter, everything else can, and think should use HTTP when it is not necessary.
Depending on yet another third party to provide what is IMHO a luxury should not be required, and I have been continually confused as to why it is being forced down everyone's throat.
It’s static while you control it. Soon as I MIIT your content it will look to your users like you updated your site with a crypto miner and a credit card form. You can publish your site with a self-signed key if you’d like and only depend on your ISP/web host provider, DNS provider, domain registrar, and the makers of your host OS and web server and a few dozen other things.
You just clearly don’t understand it is important that no one injects anything into your code while I am browsing it.
With http it is trivial.
So you say you don’t care if my ISP injects whole bunch of ads and I don’t even see your content but only the ads and I blame you for duping me into watching them.
Nowadays VPN providers are popular what if someone buys VPN service from the shitty ones and gets treated like I wrote above and it is your reputation of your blog devastated.
My ISP does not and if yours does, vote with your money or lobby your government to make this illegal.
And while at it, lobby to make corporate MiTM tools illegal as well.
Because if you are bothered about my little blog, you should be bothered that your employer can inspect all your HTTPS traffic.
There are good arguments for it, but it's also not a coincidence that they happen to align with Google's business objectives. Ex it's hard to issue a TLS cert without notifying Google of it.
I don't get your logic/reasoning here... could you explain?
> HTTPS should be for things that matter
If that were the universal state, then it would be easy to tell when someone was visiting a site that mattered, and you could probably infer a lot about it by looking at the cleartext of the non-HTTPS side they were viewing right before they went to it.
You can already see what site someone visits with HTTPS. It's in the Client Hello, and is important for things like L4 load balancing (e.g. HAProxy can look at the host to choose what backend to forward the TCP packets for that connection to without terminating TLS). It's also important for network operators (e.g. you at home) to be able to filter unwanted traffic (e.g. Google's).
I don't think seeing the site is too important, although there are TLS extensions to encrypt that, too[0]. In practice, a huge chunk of sites still have unique IPs, so seeing that someone is connecting to 1.2.3.4 gives you a pretty good idea of what site they're visiting. That's even easier if they're using plaintext DNS (i.e. instead of DoH) so that you can correlate "dig -t a example.com => 1.2.3.4" followed immediately by a TCP connection to 1.2.3.4. CDNs like Cloudflare can mitigate that for a lot of sites, but not millions of others.
However, the page you're fetching from that domain is encrypted, and that's vastly more sensitive. It's no big deal to visit somemedicinewebsite.com in a theocratic region like Iran or Texas. It may be a very big deal to be caught visiting somemedicinewebsite.com/effective-abortion-meds/buy. TLS blocks that bit of information. Today, it still exposes that you're looking at plannedparenthood.com, until if/when TLS_ECH catches on and becomes pervasive. That's a bummer. But you still have plausible deniability to say "I was just looking at it so I could see how evil it was", rather than having to explain why you were checking out "/schedule-an-appointment".
[0]https://developers.cloudflare.com/ssl/edge-certificates/ech/
https://blog.cloudflare.com/announcing-encrypted-client-hell...
Yes that's why I listed a couple reasons why adopting ECH everywhere is not straightforwardly all good. The network operator one in particular is I think quite important. It happens that the same company with the largest pushes for "privacy" (Google) has also been constantly making it more difficult to make traffic transparent to the actual device owner (e.g. making it so you can't just drop a CA onto your phone and have all apps trust it). Things like DoH, ECH, and ubiquitous TLS (with half the web making an opaque connection to the same Cloudflare IPs) then become weaponized against device owners.
AFAIK it's still not that widely adopted or can be easily blocked/disabled on a network though.
That sounds like an Android issue, not a TLS issue. If I need to break TLS I can add my own CA. Not having TLS is not the solution. Google will find other ways to take control from you.
Just because you don't care doesn't mean nobody cares. I don't want anyone snooping on what I browse regardless of how "safe" someone thinks it is.
My navigation habits are boring but they are mine, not anyone else's to see.
A server has no way to know whether the user cares or not, so they are not in a position to choose the user's privacy preferences.
Also: a page might be fully static, but I wouldn't want $GOVERNMENT or $ISP or $UNIVERSITY_IT_DEPARTMENT to inject propaganda, censor... Just because it's safe for you doesn't mean it's safe for everyone.
So... do you refuse to use the laptop supplied by your employer?
It does MITM between you and the HTTPS websites you browse.
This is still not that common but I used to work on a commercial web proxy that did exactly this. The only way it works is if the company pushes out a new root certificate via group policy (or something similar) so that the proxy can re-encrypt the data. Users can tell that this is being done by examining the certificate.
But this is mostly a waste of time, these days companies just install agents on each laptop to monitor activity. If you do not own the machine/network you are using then don’t visit sites hat you don’t want them to see.
It doesn't MITM anything. Do you see that as normal? Because I don't. We're adults here and I'm a tech guy, there's zero reason to control anything in my laptop.
In fact it's just a regular laptop that I fully control and installed from scratch, straight out of Apple's store. As all my company laptops have been.
And if it was company policy I would refuse indeed. I would probably not work there in the first place, huge red flag. If I really had to work there for very pressing reasons I would do zero personal browsing (which I don't do anyways).
Not even when I was an intern at random corpo my laptop was MITMed.
Using an employer-issued computer for anything but work for that employer is foolish, for a multitude of legal and other reasons. Privacy is just one of them.
Agreed. I think that the push to make everything HTTPS is completely unnecessary, and in fact counterproductive to security. By throwing scary warnings in front of users when there is no actual security threat, we teach users that the scary warnings don't matter and they just should click past them. Warning when a site doesn't use TLS is a clear cut case of crying wolf.
Doesn't that mean that technically, any node in the network between you and your reader can mutate the contents of the blog in-transit without anyone being the wiser (up to and including arbitrary JavaScript inline injection)?
Probably a low-threat security risk for a blog.
Yes, hotels were injecting ads on their free WiFi - https://news.ycombinator.com/item?id=3804608
ISPs have been known to do the same thing.
Devil's advocate, but maybe ISPs should all inject ads to make a point. They make money, and anyone using HTTP gets taught a free lesson on what MITM means
Before turning on the dude who thrives to keep the internet free, fix your corporate laptop that does MITM even for HTTPS connections.
I'd be happy if EU outlawed this instead of outlawing encryption.
But indeed, the ability to publish on my own outweights the risk of someone modding my content.
Most of us here read their news from work laptops, where the employer and their MiTM supplier are a much bigger threat even for HTTPS websites.
This puts the question into my brain, which I have never thought to pursue, of whether you could offer a self-signed cert that the user has to install for HTTPS.
Their client will complain loudly until and unless they install it, but then for those who care you could offer the best of both worlds.
Almost certainly more trouble than it's worth. G'ah, and me without any free time to pursue a weekend hobby project!
Mmmm, great that and mandatory key rotation every 90 days, plus needing to get a cert from an approved CA, means just that more busy work to have an independent web presence.
I don't like people externalizing their security policy preferences. Yes this might be more secure for a class of use-cases, but I as a user should be allowed to decide my threat model. It's not like these initiatives really solve the risks posed by bad actors. We have so much compliance theater around email, and we still have exactly the same threats and issues as existed twenty years ago.
I distinctly remember trying to sign up for Pandora’s premium plan back in 2012 and their credit card form being served and processed over HTTP. I emailed them telling them that I wanted to give them my money if they would just fix the form. They never got back to me or fix it for several more years while I gave my money to Spotify. Back then HTTPS was NOT the norm and it was a battle to switch people to it. Yes it is annoying for internal networks and a few other things but it is necessary.
In the early to mid 2000s I would believe this. But for a major e-commerce provider in 2012? That seems vanishing improbable.
PCI DSS is the data security standard required by credit card processors for you to be able to accept credit card payments online. Since version 1.0 came out in 2004, Requirement 4.1 has been there, requiring encrypted connections when transmitting card holder information.
There’s certainly was a time when you had two parts of a commerce website: one site all of the product stuff and catalogs and categories and descriptions which are all served over HTTP (www.shop.com) and then usually an entirely separate domain (secure.shop.com) where are the actual checkout process started that used SSL/TLS. This was due to the overhead of SSL in the early 2000s and the cost of certificates. This largely went away once Intel processors got hardware accelerated instructions for things like AES, certificates became more cost-effective, and then let’s encrypt made it simple.
Occasionally during the 2000s and 2010s you might see HTML form that were served over HTTP and the target was an HTTPS URL but even that was rare simply because it was a lot of work to make it that complex instead of having the checkout button just take you to an entirely different site
I remember even back in the early 2000s https for credit card forms was pretty common. Surprised a company like Pandora wasn't with it by thr 2010s.
Doesn't it already do this? I keep a domain or two on HTTP to force network-level auth flows (which don't always fire correctly when hitting HTTPS) and I've gotten warnings from Chrome about those sites every time for years... Only if I've been to the site recently does the warning not show up.
Right now it only shows a little bubble in the URL bar saying "Not Secure", I think. (So, that is a "warning", in a sense.) TFA is saying there will now be an interstitial if you attempt an HTTP connection.
HSTS might also interact with this, but I'd expect an HSTS site to just cause Chrome to go for HTTPS (and then that connection would either succeed or fail).
> to force network-level auth flows (which don't always fire correctly when hitting HTTPS)
The whole point of HTTPS is basically that these shouldn't work, essentially. Vendors need to stop implementing weird network-level auths by MitM'ing the connection, and DHCP has an option to signal to someone joining a network that they need to go to a URL to do authentication. These MitM-ers are a scourge, and often cause a litany of poor behavior in applications…
HTTPS url?
Chrome has shown the HTTP warning in Incognito mode for about a year, and has shown the warning if you're in Advanced Protection mode for about 2-3 years.
http://http.rip/ is useful for testing this sort of thing. I used to test with http://neverssl.com/ until they added HTTPS for some reason.
> I used to test with http://neverssl.com/ until they added HTTPS for some reason.
My first reaction was along the lines of "What? That can't possibly be right..."
After testing a bit, it looks like you can load https://neverssl.com but it'll just redirect you to a non-https subdomain. OTOH, if the initial load before redirecting is HTTPS then it shouldn't work on hotel wifi or whatever, so still seems like it defeats the purpose.
Huh.
neverssl added an HTTPS version for browsers that automatically connect to HTTPS when entering a domain name (like Chrome probably will after this change, eventually). The HTTPS version of the site uses Javascript to load a random http:// subdomain of neverssl.com so automatic HTTPS redirects are still defeated.
http.rip will probably show a "website unavailable" error at some point unless you manually type in the http:// prefix.
IANA's http://example.com still has a plain http version.
i use http://perdu.com
http://www.slackware.com/ is probably the biggest website I'm aware of that does not serve encrypted traffic[1]. but there are a few other legitimately useful resources that don't encrypt.
[1] (Except on the arm subdomain for some reason)
My first distro was Slackware. Good memories. The ARM subdomain looks drastically more maintained, posts from 2025.
Don't ever view source on slackware.com
> Don't ever view source on slackware.com
why ?
Don't ever view source on slackware.com
Awwww, that's the stuff right there.
As good an idea as this is... I do hope that localhost/127.0.0.1 will be excluded for devs/testers.
What's worse, many plaintext HTTP connections today are entirely invisible to users, as HTTP sites may immediately redirect to HTTPS sites. That gives users no opportunity to see Chrome's "Not Secure" URL bar warnings after the risk has occurred, and no opportunity to keep themselves safe in the first place.
Two hosting providers I use only offer HTTP redirects (one being so bad it serves up a self signed cert on the redirect if you attempt HTTPS) so hopefully this kicks them into gear to offer proper secure redirects.
What defines private sites, I wonder – beyond "such as local IP addresses like 192.168.0.1, single-label hostnames, and shortlinks like intranet/"?
Non-unique hostnames, which are RFC 1918 space, single-label hostnames, and addresses assigned to mDNS (.local).
Single label hostnames had an issue where it’s hard to type them into a browser.
How to fix this?
Usually, completing the domain name by adding the final period will do the job. Instead of entering myprinter into the address bar, try myprinter. so your DNS server doesn't try to resolve myprinter, myprinter.domain, myprinter.domain.tld, and whatever other search domains have been configured. A real, fully-qualified domain ends in a period, though most tools will happily let you avoid that final period.
Alternatively, .local domains will work for mDNS-capable devices (and non-mDNS-capable devices if you like to risk things breaking randomly), and the .internal TLD has been reserved so .internal domains should also work for local addresses.
Add a /, e.g. `shortname/`
Does this apply to requests made by JS or just page loads?
Security theatre is all it is. Protect us from petty thieves but let our employers and the gov MITM our comms.
"cannot connect" is next ?
Thanks God, i am not using google
Good stuff.
Anyone have a good recipe for setting up an HTTPS for one-off experiments in localhost? I generally don't because there isn't much of a compromise story there, but it's always been a security weakness in how I do tests and if Chrome is going to start reminding me stridently I should probably bother to fix it.
How exactly are unencrypted localhost connections a security weakness? To intercept the data on a loopback connection you'd need a level of access where encryption wouldn't really add much privacy.
Chrome treats localhost as a secure origin (regardless of HTTPS) by default - don't overthink it.
Oh, groovy; if they keep doing that I'm all good, since I usually do one-off remote stuff by SSH tunnels anyway.
I haven't used it, but I think `mkcert` is the go to solution for this. [0]
[0]: https://github.com/FiloSottile/mkcert
> HTTPS adoption expressed as a percentage of main frame page loads
Why is Linux adoption at 80% when MacOS/Android/Windows are at 95%? Quite unexpected.
They mention it later in the article; if they drop connections to internal networks from the graph, Linux shoots up all the way to 97%.
The answer is probably that people that run Linux are far more likely to run a homelab intranet that isn't secured by HTTPS, because internal IP addresses and hostnames are a hassle to get certificates for. (Not to mention that it's slightly pointless on most intranets to use HTTPS.)
This is addressed in the article.
> If you exclude navigations to private sites, then the distribution becomes much tighter across platforms. In particular, Linux jumps from 84% HTTPS to nearly 97% HTTPS when limiting the analysis to public sites only.
Sounds like it's just because a large chunk of Linux usage is for web interfaces on the local machine or network, rather than everyday web browsing.
Tendency of Linux users to have local resources that lack TLS? phpmyadmin, netdata, duckdb ui, git-webui, whatever.
Silly question and one I should probably already know the answer to but never really got around to thinking through: are there practical concerns for not doing TLS in your home intranet?
It means that if someone has patched into your local network they can access anything in there, but they have to get in first, right? So how concerned should one be in these scenarios
(a) one has wifi with WPA2 enabled
(b) there's a Verizon-style router to the outside world but everything is wired on the house side?
Main reason is that it's hard to get certificates for intranets that all devices will properly trust.
Public CAs don't issue (free) certificates for internal hostnames and running your own CA has the drawback that Android doesn't allow you to "properly" use a personal CA without root, splitting it's CA list between the automatically trusted system CA list and the per-application opt-in user CA list. (It ought to be noted that Apple's personal CA installation method uses MDM, which is treated like a system CA list). There's also random/weird one-offs like how Firefox doesn't respect the system certificate store, so you need to import your CA certificate separately in Firefox.
The only real option without running into all those problems is to get a regular (sub)domain name and issue certificates for that, but that usually isn't free or easy. Not to mention that if you do the SSL flow "properly", you need to issue one certificate for each device, which leaks your entire intranet to the certificate transparency log (this is the problem with Tailscale's MagicDNS as a solution). Alternatively you need to issue a wildcard certificate for your domains, but that means that every device in your intranet can have a valid SSL certificate for any other domain name on your certificate.
> get a regular (sub)domain name
You can get $2/yr domain names on weird TLDs like .site, .cam, .link, ...
> which leaks your entire intranet to the certificate transparency log
Not necessarily, you don't route the domain externally, and use offline DNS challenge/request to renew the certificate.
> You can get $2/yr domain names on weird TLDs like .site, .cam, .link, ...
You can, but as stated - that's not free (or easy). That's still yet another fee you have to pay for... which hurts adoption of HTTPS for intranets (not to mention it's not really an intranet if it's reliant on something entirely outside of that intranet.)
If LetsEncrypt charged 1$ to issue/renew a certificate, they wouldn't have made a dent in the public adoption of HTTPS certificates.
> Not necessarily, you don't route the domain externally, and use offline DNS challenge/request to renew the certificate.
I already mentioned that one, that's the wildcard method.
Perhaps you might worry about hostile IOT doodads snooping on things that arent their business or making insecure public webpages with UPNP. If it is just devices you truly control and you never expose an unhardened device, then a walled garden can be fine.
Also, if WPA2 ever becomes extremely broken. There was a period of 3-5 yrs where WEP was taking forever to die at the same time that https was taking forever to become commonplace and you could easily join networks and steal facebook credentials out of the air. If you lived in an apartment building and had an account get hacked between maybe 2008-2011, you were probably affected by this.
Everything that matters in your home intranet should already be password protected and firewalled.