Enforced https on public sites

[suzyne]

Moderator note: split off off-topic tangent.

Ah, the good old days of no enforced https for public sites that don't need a login

Interestingly, the government run weather website in Australia still only uses a non-secure URL, and doesn't even allow https connections.

http://www.bom.gov.au/

I read somewhere that the reason for this is that there are countless hardware and weather related devices (I think mostly used by farmers?) out there that have been scraping the site for many years to get the important data and the BOM is too worried about breaking them, and so the site has no plans to change.

I can't remember which browser it was, but there was a time when I couldn't easily visit the site because the browser would refuse the BOM as "not secure".

[moonbat]

I read somewhere that the reason for this is that there are countless hardware and weather related devices (I think mostly used by farmers?) out there that have been scraping the site for many years to get the important data and the BOM is too worried about breaking them, and so the site has no plans to change.

Good to know. It makes zero sense to force a website owner to rent an SSL certificate when they're not storing any credentials or financial information.

[Moonchild]

It makes zero sense to force a website owner to rent an SSL certificate when they're not storing any credentials or financial information.

100% agree.

I still think public information doesn't need to be shoved behind encryption. It should be open and freely available -- it would actually make caching much simpler too and help the overall health of the Internet as a whole.
Encryption proponents have traditionally bucked against that by saying "oh but someone might change the information in-transit!". I think if that's your (unlikely) situation, then you have bigger problems than being misinformed of public info...

[moonbat]

Encryption proponents have traditionally bucked against that by saying "oh but someone might change the information in-transit!"

Has anyone ever MITMed a plain HTTP site? AFAIK that is only ever done to steal credentials or non public information. If someone is using credentials over plain HTTP then it's totally their fault.

[Moonchild]

Has anyone ever MITMed a plain HTTP site?

I think only to show that it could be done. Maybe in some cases for censorship also? Although that's much easier done by a simple DNS redirect or IP block or something.
I also don't know of any serious instance outside of the "proving it could be done" where downloads were replaced by a MitM with malware (it would be hardly feasible outside of very specific targeted attacks). So, for all intents and purposes, no, I don't think so.
But as I said before, the security landscape is fraught with purists throwing the feasibility factor out the window when it served their push for https everywhere all the time.

[BenFenner]

It makes zero sense to force a website owner to rent an SSL certificate when they're not storing any credentials or financial information.

100% agree.

Really you two (and others around here) should know better. It's obnoxious how Google forced SSL/TLS the way they did, but the result was A Good Thing™.

I'm pasting something I posted on a completely different forum to save myself some typing:

This is the part lost on most proponents of unencrypted traffic. For some reason they seem to think that sending benign text or files in the clear is not an issue. Even people who should know better.

The problem is two fold:

1) A MITM attack can change anything on its way to the user and now you and/or your user suffer, because the traffic is unencrypted.

This can go wrong in a million ways. If you're not creative enough to see why, then imagine you may be trying to host/send a recipe for salad dressing, but the user ends up getting a recipe for mustard gas.

Sometimes checksums are provided for files which is given as a defense against any trouble with this issue. It sort of helps, sometimes, (if the user goes through the trouble, and the checksum itself hasn't been altered as well) but doesn't help at all with the issue below.

2) The text or files are benign in your and your server's country, but illegal in the destination country (think places with horrible human-rights records) which means you're screwing over users in those places who might benefit from encryption. (Or similarly, bad actors in any country get a hold of the otherwise benign comms and use it against your user in situationally unique ways you never imagined.)

I've held my tongue on this for way too long. Pale Moon downloads should be encrypted. Doing otherwise is a huge middle finger to those in places like North Korea or wherever that could suffer real consequences because of this project's asinine decisions.

Being a privacy-minded project but also being completely blind to the way unencrypted HTTP traffic can be used against the user (looks like the former spouse in this case viewed such and such content at such and such time so they lose such and such OR looks like the abuser learned such and such about their victim's online behavior and used it to inflict such and such additional harm) really boggles the mind these days.

If someone is using credentials over plain HTTP then it's totally their fault.

Cool victim-blaming.

[vannilla]

Neither those two points invalidate Moinchild's argument nor do they provide a case for encrypting everything.
The first point is literally what Moinchild said: it is feasible only for targeted attacks, generalizing hypothetically does not make it magically feasible everywhere. For both sides the MITM boogeyman is sophistry.
Point two is irrelevant. If I live in the EU and host my site on a server located in the EU and the EU allows me to talk about the Tienanmen Square incident, it is not my responsibility if an oppressed chinese citizen gets arrested because it visited my site. If I offer protection is entirely out of goodwill and I should not be condemned if I don't care about it.

[moonbat]

A MITM attack can change anything on its way to the user

So what is the benefit of doing that for publicly available information on a public website that has zero confidentiality to begin with? How many such cases have you heard of against public sites that don't require a login and what exactly does the attacker hope to achieve by doing this (as opposed to directly hacking the site itself based on some vulnerability and defacing the main page - as several groups have done)?

Cool victim-blaming.

Let me put it another way. HTTPS exists precisely for such situations when you are authenticating a user and for several years it worked great when a normally HTTP site would hand over the authentication to an HTTPS subdomain and then stay on HTTPS while the user was logged in. If website owners/developers/maintainers choose to not use this mechanism that dates to the previous century and send credentials over clear HTTP, they are dumbfucks, not victims.

[suzyne]

My 2 cent observations, which are probably worth even less based on my understanding of the issues, are that...

I think it is unfair to put it all on Google. (Although, for this forum, that is to be expected.) From what I have read, Let's Encrypt, EFF and Mozilla were/are also behind the push for HTTPS.

About people in countries with inadequate human rights, I hope they rely on more than HTTPS to stay safe when accessing things that could get them in trouble. If they aren't using a VPN, don't they need to be very concerned about their ISP and DNS logs?

Sorry, this is more of a question, but what does "Pale Moon downloads should be encrypted" mean?

[Moonchild]

The text or files are benign in your and your server's country, but illegal in the destination country

My approach is not one of extremes. In this context:

If I offer protection is entirely out of goodwill and I should not be condemned if I don't care about it.

Which leads to the practice to offer both http and https for public data as a matter of goodwill if that public data could be considered illegal for some visitors, but even then, the oppressed user should simply use https to tunnel out of the oppressed section of the internet through an encrypted tunnel to access the cleartext, if the webmaster doesn't offer https for the content.

It's obnoxious how Google forced SSL/TLS the way they did, but the result was A Good Thing™.

No, it was not. Before all this became commonplace I already predicted the issues it would bring, and thus far I have not been proven wrong. In fact, it's become worse with how encryption has become such a commodity that its value has been greatly reduced. Let's Encrypt is an absolutely terrible certificate service that happily keeps certs alive that were issued to bad actors, for example. Getting https set up for fake sites used to be hard for a reason, and any CA supporting such practices used to be punished harshly. Point in case: StartCom was killed over being associated with (not even guilty themselves of!) a CA accused of the same stuff Let's Encrypt started doing right after (but much worse), taking its place.

For the time being though it is what it is and the internet is mostly encrypted pointlessly, but the fact that this situation exists doesn't mean our principles and underlying reasoning for disagreeing with the practice is wrong. Maybe, when broad segmentation happens, people will revisit this. Maybe not. I don't have a crystal ball.

[BenFenner]

So what is the benefit of doing that for publicly available information on a public website that has zero confidentiality to begin with?

Your question is answered multiple ways in my original post.

Sorry, this is more of a question, but what does "Pale Moon downloads should be encrypted" mean?

Sorry, what I said is confusing out of context. What I meant was, the downloadable Pale Moon executables provided by this web site should be provided over encrypted channels. (This is a debate that's been going on for a long time on this forum and I finally wanted to chime in.)

[Moonchild]

Your question is answered multiple ways in my original post.

If you mean the premise of:

This can go wrong in a million ways. If you're not creative enough to see why, then imagine you may be trying to host/send a recipe for salad dressing, but the user ends up getting a recipe for mustard gas.

To stick with that example: Unless you plan on modifying every source of information about salad dressing, everywhere, for a reasonably large swathe of the population, what's the point? What benefit would a hacker have other than (maybe) misinforming the visitor about public, non-confidential information? Why would they invest in such a campaign of misinformation? There's no value in it. Beyond playing a prank on someone, perhaps.
So, the question what the benefit is of encrypting publicly available information on a public website that has zero confidentiality really isn't answered by that, at all.

Sorry, what I said is confusing out of context. What I meant was, the downloadable Pale Moon executables provided by this web site should be provided over encrypted channels. (This is a debate that's been going on for a long time on this forum and I finally wanted to chime in.)

And the answer is and will remain a firm no. There is no ongoing debate, it's been settled. We may agree to disagree here but there isn't anything new here. Forcing https downloads for all would create a chicken-and-egg problem. You need a modern browser to download from a modern-TLS secured https website, but you can't do that if the thing you want to download is the very browser you'd need. If all you have is a rudimentary or old browser or download tool, the encrypted channels would fail, unless I would compromise on the TLS security for everyone else making it deliberately weak by 2025 standards.
If you download over http, then you should use the provided hashes or (preferred) PGP signatures to verify your download is what you expected, which would firmly undercut any potential MitM download injection (which we really haven't seen much of in the wild, at all).

[moonbat]

Salad dressing to mustard gas? Do you even threat model bro? Or do you get all your ideas from Hollywood hackers? The way it stands now, enforced HTTPS everywhere is an unnecessary gatekeeping for someone even wanting to put up a simple webpage hosted on its own domain because apparently such pages used to get MITMed all the time and it's totally not a fresh revenue model for CAs

[RealityRipple]

To be clear, my site isn't always enforced https - it uses a 307 (or 302 on http 1.0) if you send the UIR header, and as a fallback it uses a javascript redirect if you can successfully load an https script off the http site. Meaning if not for caching and https-based links, the site would have still loaded. realityripple.net specifically has no attached certificate, and will never be cached with an https redirect, so it was easier than saying "try a private tab or new profile".

[Moonchild]

I took a different approach a while back for www.palemoon.org that I'll share here, because it seems to work pretty well.
I offer both http and https for the website. https is using modern encryption (TLS1.2+1.3) with an ECC certificate.
http forwards to https automatically, but only if the web client (browser) is using http and requests it by sending the "upgrade-insecure-requests" header, indicating it's a modern browser that prefers https by default through opportunistic encryption, i.e. the web server takes that opportunity to switch protocols to https.
While testing a JS load from https is an idea it still does more than I'd want to, because you're forcing things to https without choice in that case.

I think that's the best balance of accessibility and security, and leaving the choice in the web visitor's hands.

Details below for curious techies.

In nginx there's the option to directly check for this request header (not to be confused with the CSP directive of the same name!) with $http_upgrade_insecure_requests.
It gets a little tricky if you want to prevent redirect loops, so you must at all times check if a user is not already on https and is sending this header, and only then send a redirect.
I've done it using a $test variable in nginx to store the states to check. I'm sure there might be a clever, more compact way to check it with a single if statement or something, but this works and is readable so I stuck with it:

Code: Select all

    location / {

        if ($scheme = 'http') {
            set $test "H";
        }
        if ($http_upgrade_insecure_requests = 1) {
            set $test "${test}U";
        }
        if ($test = HU) {
            return 302 https://$host$request_uri;
        }
        
        ...
    }

[Veit Kannegieser]

In the company i work for we have MITM quite regularly now.
Before, McAfee Web Gateway was used, needed user name + password for internet access, i have used a proxy chain with CNTLM to help with that.
Now ZScaler is used, and that inserts js into HTTP and redirects to a login page, HTTPS is either answered with their own cert (lunch plan of canteen or www.archive.org),
or passed unharmed.
But many sites offer odd translation, since the GeoIP databases think that we are from Denmark now.

For my own site so far good results with Let's Encrypt certificates, nicely automated.
So in case of a problem and resulting revoke, no e-mail/phone contact and manual work would be needed.

Thanks for the hint for observing the Upgrade-Insecure-Requests: header.

[Moonchild]

In the company i work for we have MITM quite regularly now.

What you're talking about is intentional MitM by gateway middleboxes or AV -- we're talking about malicious MitM inserting itself between you and the server somewhere along the route. Different scenario.

So in case of a problem and resulting revoke, no e-mail/phone contact and manual work would be needed.

You're assuming Let's Encrypt revokes certificates. They don't! So, your compromised cert can be used by a bad actor for whatever the lifetime is. This also includes certs they themselves issued incorrectly if/when their CA gets tricked into believing the 1-factor request for a cert, like hijack/replay/etc..
I hope you are aware of that.

CAA (if you're using a real CA fro certs) is an attempt at mitigating this disaster but it really just shifts the responsibility to DNS which is not outside of the MitM realm either. It's kind of a dumpster fire as a result; with nobody wanting to try and fix the root cause and instead just stacking more countermeasures on top, but it is what it is for now.

[Veit Kannegieser]

What you're talking about is intentional MitM by gateway middleboxes or AV -- we're talking about malicious MitM inserting itself between you and the server somewhere along the route. Different scenario.

True. Still have to to adjust search results (stack overflow..) to https. Nice when both works.
Also had to construct special handling for non-browser tools.

You're assuming Let's Encrypt revokes certificates. They don't! So, your compromised cert can be used by a bad actor for whatever the lifetime is. This also includes certs they themselves issued incorrectly if/when their CA gets tricked into believing the 1-factor request for a cert, like hijack/replay/etc..
I hope you are aware of that.

Yes, its mixed like https://bugzilla.mozilla.org/show_bug.cgi?id=1619179#c7 (LE). Part of the excuse is short cert live time.
Happens for other "real" CAs too https://bugzilla.mozilla.org/show_bug.cgi?id=1947691 (NETLOCK) and https://bugzilla.mozilla.org/show_bug.cgi?id=1965612 (Microsoft).
In my opinion LE improved the certificate generation quite well with in the limits of the "1-factor".

I use CAA too, kind of in opposite direction.

[frostknight]

100% agree.

I still think public information doesn't need to be shoved behind encryption.

I can agree to this as long as it is easy to undo any interference if it happens.

[Moonchild]

Part of the excuse is short cert live time.

That's no excuse. There's a very, very good reason we have systems in place for cert revocation. OCSP, stapled OCSP and CRLs exist and are checked by browsers for a reason. Whether a cert has a lifetime of a month, 3 months or a year makes no difference!
Additionally, malicious actors hijacking certs can do plenty of damage in whatever lifetime LE sets. A CA response in that case should be much faster. We're talking about days, not months, here.