> For some reason, this page doesn't have a 301 redirect set up when you access the plain HTTP page.
My opinion on the topic:
I think that's perfectly reasonable. Why would they want to force users to use TLS? I don't understand the appeal of HTTP->HTTPS 301 redirects on every single website.
A static document is served on the linked page, no passwords are transmitted. Plaintext is perfectly enough for fulfilling requests for this document. TLS would just use more processing power and time to deliver the document.
If the website visitor is interested in downloading the document encrypted, he is free to use the HTTPS protocol with a browser setting.
If the website publisher is interested in sending the document encrypted, he is free to use HSTS or the redirect hack you described.
But I don't see any reason why noiseprotocol.org would like all connections to them being encrypted; they are not an online bank. Enforcing TLS just prevents visitors without TLS support from being able to view documents on their website.
> A static document is served on the linked page, no passwords are transmitted. Plaintext is perfectly enough for fulfilling requests for this document. TLS would just use more processing power and time to deliver the document.
While I don't have hard figures for the traffic volume for this domain, I'd wager it's on the order of 100,000 requests a month -- maybe on the order of a million on the high end. That's something you can easily handle with a micro instance in AWS as an example, and under almost every cloud hosting pricing scheme, the extra cost from the (honestly, quite minimal) difference in power from serving HTTPS rather than HTTP isn't billed. The additional time to deliver a document over HTTPS is imperceptible to humans on any remotely modern (last ~15 years) hardware on almost any connection outside of the absolute worst network environments.
That it doesn't receive sensitive data is moot -- it sends what can easily be considered sensitive data. White papers about encryption and obfuscation protocols are often of interests to, for example, political dissidents both in countries where they're at risk and abroad, and they may be targeted in either case. Modern extensions like ECH (which is beginning to be widely available[0]) offer a degree of protection against that, and prevent snooping in general.
Political dissidents aside, it's another channel advertisers can use to see your browsing habits and build up a targeted advertising profile. There have been isolated incidents where ISPs were caught injecting ads into users' pages; I think a more realistic issue would be ISPs auctioning off browsing histories.
> If the website visitor is interested in downloading the document encrypted, he is free to use the HTTPS protocol with a browser setting.
We live in a world where almost all content is delivered over HTTPS thanks to the efforts of orgs like LetsEncrypt. I wouldn't have noticed that that document is plain-HTTP if not for the fact that I decided to toggle Firefox's HTTP-only mode earlier that day just to see what impact it has on day-to-day browsing.
Most people aren't careful about this, and most people probably prefer privacy if the option costs them nothing and takes no time.
> But I don't see any reason why noiseprotocol.org would like all connections to them being encrypted; they are not an online bank. Enforcing TLS just prevents visitors without TLS support from being able to view documents on their website.
"Visitors without TLS support" represents a vanishingly small number of people that I don't even know how to describe. Who would this even be, in practical terms?
These are arguments why people would want to access the content over a secure encrypted channel, not reasons for the website to force them to; and, in fact, in this frame, it frankly seems like a BAD idea to SILENTLY force them to, as that first request to the http URL is where the game is already lost: an attacker which can do any of the things you are positing wins immediately upon seeing the first http connection attempt, as they 1) now know what website you are accessing and 2) can hijack that request and move you to an entirely different site.
Adding that silent redirect, then, merely looks or feels safer, but, at best, seems more likely to encourage broken behavior among users, who now might always see secure locks in their browser but not realize all of the links they are clicking were insecure and so the chain of trust on their location is now tainted. In contrast, none of the alternatives -- 1) not listening on port 80, 2) replacing the http website with a stub which asks users to manually change the scheme to https, or 3) providing two copies of the website (one that is secure and one that isn't) -- seem anywhere near as dangerous.
(BTW, you are also ascribing magical protection properties to ECH: in addition to the obvious issues with the IP address of a server usually being sufficient to tell what website someone is using, TLS fails to protect users against content fingerprint attacks--think stuff like figuring out what part of Google Maps you are looking at, what video in YouTube you are watching, or even what query you are typing into a search bar"--and so isn't really a sufficient basis for protecting someone against persecution. You need some kind of Internet overlay network to even begin to approach that problem, converting it back into the integrity problem.)
> The additional time to deliver a document over HTTPS is imperceptible to humans on any remotely modern (last ~15 years) hardware on almost any connection outside of the absolute worst network environments.
b:~[0]# time curl --no-progress-meter --output /dev/null http://noiseprotocol.org
real 0m0,353s
user 0m0,004s
sys 0m0,003s
b:~[0]# time curl --no-progress-meter --output /dev/null https://noiseprotocol.org
real 0m0,705s
user 0m0,041s
sys 0m0,006s
b:~[0]#
It takes double the time to load the page with TLS. No matter the hardware and network (tested with high bandwidth low latency not congested FTTH) you can't go faster than the speed of light and the additional TLS handshake does not make loading any faster.
Notice also the increase in CPU time when using HTTPS (user field in time).
> That it doesn't receive sensitive data is moot -- it sends what can easily be considered sensitive data. White papers about encryption and obfuscation protocols are often of interests to, for example, political dissidents both in countries where they're at risk and abroad, and they may be targeted in either case. Modern extensions like ECH (which is beginning to be widely available[0]) offer a degree of protection against that, and prevent snooping in general.
AFAIK ECH only works with a central MiTM proxy like cloudflare, not with a selfhosted page. It's debatable what privacy implications hosting using cloudflare has. You cannot prevent the hostname from being sent in plaintext to a selfhosted third party website if you want SNI, which servers often expect clients to send. EDIT: ECH is disabled globally on Cloudflare currently: https://developers.cloudflare.com/ssl/edge-certificates/ech/
Whenever you connect via TLS, Firefox sends an unencrypted OCSP HTTP request to the CA servers that includes the hostname. Yet another thing that slows you down when requesting websites protected by TLS that wasn't measured in my curl benchmark (unless OCSP stapling is used, of course).
> Political dissidents aside, it's another channel advertisers can use to see your browsing habits and build up a targeted advertising profile. There have been isolated incidents where ISPs were caught injecting ads into users' pages; I think a more realistic issue would be ISPs auctioning off browsing histories.
ISPs can only do that if you allow them to. Where I live, they can't; it's forbidden by law and network history is considered personal data. Injecting ads is also illegal where I live; ISPs tampering with anything above layer 3 is not allowed as per Internet neutrality laws here.
Just the IP address is enough to figure out someone is browsing the Noise Protocol website: Try visiting http://138.68.46.44
> I wouldn't have noticed that that document is plain-HTTP if not for the fact that I decided to toggle Firefox's HTTP-only mode earlier that day just to see what impact it has on day-to-day browsing.
Maybe set this your browser up so that it automatically changes the protocol to HTTPS from HTTP without failing? This way, you wouldn't've noticed any issue at all.
Bottom line: There is no reason to force users to use TLS on noiseprotocol.org and doing so would be worse for users of the website without providing much benefits.
For some reason, this page doesn't have a 301 redirect set up when you access the plain HTTP page.