Pale Moon forum

Well I should add that certificate errors are actually still somewhat frequent when doing this (I've gotten so used to them that I consider them normal, although I never accept one without checking what's wrong -and almost never permanently- ).

So it's better to have some knowledge about the subject.

In most cases it's just that the certificate doesn't include the visited domain because the site uses a not-appropriately-configured CDN or https hasn't explicitly been enabled yet, but it will still work alright after accepting -temporarily- the certificate (of course with much more limited security guarantees).
In others you'll be directed to the site's admin panel (and this means that the site only works through http).
Those that don't accept the connection or return some error are rarer.

But a normal user could simply consider those as some of the errors that ought to lead him to try disabling the setting/addon.
It should indeed do so, if certificate errors are to preserve any meaning, although a tls connection with an erroneous certificate is hardly ever worse than a plain http one (if the user is aware that there's no guarantee in the security of such connection).

I confirm that the wide majority of sites do work correctly, though.

gabrl wrote: ↑

2021-01-11, 18:54

The web is effectively almost entirely on https as of now.

...which underlines my point of why you should not need to force it with an extension!
The sites that aren't on https by default might not have things set up for it. The sites that do, won't need to be forced to use it because they will forward themselves.

And a server admin might be wanting to forward http requests to a different host/sub which an extension would bypass. Things like that.

Moonchild wrote: ↑

2021-01-11, 22:33

gabrl wrote: ↑

2021-01-11, 18:54

The web is effectively almost entirely on https as of now.

...which underlines my point of why you should not need to force it with an extension!
The sites that aren't on https by default might not have things set up for it. The sites that do, won't need to be forced to use it because they will forward themselves.

The reason is that the initial http request is a privacy and sometimes security (cookies) leak (especially when performing queries) and is subject to mitm modification; the interceptor will usually steer clear of upgrading to tls, but it might also redirect to a similarly-named site correctly supporting tls or just redirect to the right site after having carried out some chicanery, exploiting some vulnerability of the browser.
Of course if the connection remains plain http the user might recognize it and if he expected the site to be on https he might suspect something; that's probably not so likely to happen for normal users, though.

Certainly from a certain point on this feature should be something built into all browsers rather than an extension, and that's indeed where we're gradually going.
As mentioned in that article Firefox has already an experimental option (firefox-80-https-only-mode-in-settings) that attempts to perform some automatic handling.

Moonchild wrote: ↑

2021-01-11, 22:33

And a server admin might be wanting to forward http requests to a different host/sub which an extension would bypass. Things like that.

Sure in theory, but in my quite extensive experience I don't remember ever running into such a case, so... well I offer this mine anecdotal experience.

Of course I can't rule out that some of the sites I visited did have those forwards even though they worked with a direct tls connection too, but it's unlikely and most of all if I didn't notice problems, well in all likelihood it means that the direct tls connection was good enough.

The worst problem I remember was with a server that accepted tls connections, returned an http response on them with a HSTS policy declaration but then didn't really serve the proper web site's pages through tls. So, you would have had to use plain http, but were now stuck with a very-hard-to-cleanse HSTS setting that prevented you to do so. Twisted, but I luckily only encountered one such case.

There have been some large surveys of tls support that maybe investigated these things too, but I can't find any of them right now.
They're relatively easy to perform though if one is interested.

gabrl wrote: ↑

2021-01-12, 14:43

The reason is that the initial http request is a privacy and sometimes security (cookies) leak (especially when performing queries) and is subject to mitm modification; the interceptor will usually steer clear of upgrading to tls,

The initial request isn't a privacy or security leak because by the time you perform a specific query you should already be on the https version of the site (and if you aren't then that would be your own incorrect use of non-secure entry points and/or bookmarks). In addition, this is what HSTS is for. Cookies are also not shared between https and http because any sane browser implementation has a strict separation between the two for cookies (and we have mechanisms like cookie-secure etc. as well to restrict the use of cookies on http even IF it were initially set.
So no, those really aren't arguments to externally force https on the client-side.

Moonchild wrote: ↑

2021-01-12, 14:55

gabrl wrote: ↑

2021-01-12, 14:43

The reason is that the initial http request is a privacy and sometimes security (cookies) leak (especially when performing queries) and is subject to mitm modification; the interceptor will usually steer clear of upgrading to tls,

The initial request isn't a privacy or security leak because by the time you perform a specific query you should already be on the https version of the site (and if you aren't then that would be your own incorrect use of non-secure entry points and/or bookmarks). In addition, this is what HSTS is for.

Plain-http manual queries are indeed probably rare, I imagine by now all browsers use https addresses for their search bars.

But the specifically requested page is a leak as well, often very significant, and accessing a specific page, through a link rather than the site's root is the norm (although admittedly in many cases that happens through a google-like search engine that will first slurp which link you clicked, making privacy concerns largely moot).
Furthermore now frequently a single IP supplies many sites, and with Encrypted SNI and DNS it's now (slowly) becoming feasible to hide the indication of the site as well.

Moonchild wrote: ↑

2021-01-12, 14:55

(and if you aren't then that would be your own incorrect use of non-secure entry points and/or bookmarks)

You're arguing for a lot of care on the part of the user when (if he's comfortable with this feature) he could simply enable the addon/setting and be done with it.
Bookmarks even, a good part of the sites in an average user's bookmarks will have probably switched to https only in the last two years, to me it doesn't seem reasonable to blame the user if he hasn't still checked and rewritten all his links.

Moonchild wrote: ↑

2021-01-12, 14:55

In addition, this is what HSTS is for.

HSTS needs to be configured by the web server, many still don't (especially because it's a little risky) and in general to me it doesn't seem so much of a panacea.
When it doesn't have too many downsites I think it's always better to enforce the security features from the get-go on the client side rather than relying on the other party.

Moonchild wrote: ↑

2021-01-12, 14:55

Cookies are also not shared between https and http because any sane browser implementation has a strict separation between the two for cookies (and we have mechanisms like cookie-secure etc. as well to restrict the use of cookies on http even IF it were initially set.

I'm not up to date with all the browsers' security mechanisms, I don't know if the cookies' Secure attribute is not necessary anymore, but in general what you mention is why I said "sometimes".

Some (luckily few) sites still support plain http login; apart from that I don't know if the current browsers have already blocked all the possible ways to leak sensitive cookies in plain http.

Moonchild wrote: ↑

2021-01-12, 14:55

So no, those really aren't arguments to externally force https on the client-side.

Personally I'm not yet convinced they aren't, but most of all, there's still the mitm modification thing.



To conclude however:

1. My main point was to testify that it's feasible, I wasn't very eager to enter a debate into whether it should be done or not and by whom
2. If we have to argue fiercely whether https-first should be done or not, one thing we ought to discuss is what are the downsides. At this point you have presented the theoretical dangers, which are fair and something I also wondered about when first began experimenting, and I offered my personal experience, that gives an indication that those fears might be not so relevant in the present reality.
   Since you seem to have strong opinions against this idea, please do lay out if you see additional problems, I am really honestly interested.
   Of course my experience is just my personal one that you can't be even be sure to have really happened, it would for sure be appropriate at least before a wide-scale deployment to perform serious large surveys (on Alexa top x-million or something like that).
3. Of course the other point is what are the advantages
4. And then possibly how to do it in practice for the general public
5. Although I'm not arguing for the introduction of anything like that in Palemoon right now: it would likely make sense to wait to see what Chrome and Firefox do first, and hash out the best implementation in those projects' discussion avenues
6. I seriously hope we can have an amicable discussion, although this forum doesn't seem to be much conducive to that
7. I don't have a lot of free time in this period, so please allow me to take some time for replying, and I hope we won't drag this for too long

Works for me

Tested several plain HTTP URL's with no problem