Solved *https everywhere* as a built-in flag

e.ninger

Instead of an extension i think it would not be so difficult to have https everywhere built in... (?)

nomadic

@ccurley It is already in Vivaldi because Vivaldi uses a Chromium base.

Check out the link that you shared and you will see how to enable it.

Desktop:

Go to chrome://settings/security/ and enable Always use secure connections

Mobile:

Go to Settings → Privacy and security and enable Always use secure connections

BoneTone

@MrNoName Are you thinking of the HSTS preload list, or is this a different feature?

iAN CooG

try vivaldi://net-internals/#hsts

BoneTone

@MrNoName said in *https everywhere* as a built-in flag:

no google plans to make sites open in https instead of http if they can or you will get a error.

That's what HSTS preload does. If a site is in the HSTS preload list then the initial request to the server is made over HTTPS, preventing an SSL stripping attack. Even if you click a link or type an address with HTTP, it will be converted it HTTPS. Google runs the HSTS preload list, so I'm curious if they're actually working on another feature that does same thing.

Edit: See the link @iAN-CooG provided for your local copy (this is already in use) and this website for more details: https://hstspreload.org

BoneTone

For a little more explanation, here's the basic gist. Websites that have implemented HTTPS across their entire site obviously want their users to access it securely. Using a simple redirect on the server, they can switch users who access it over HTTP on port 80 to HTTPS on port 443.* Then the rest of their session will be secure. Once a user is connected to a site securely, the site can tell the browser that it should always connect via HTTPS, thus enforcing a "strict" policy. That information is not sent over an insecure HTTP connection.

There is still a vulnerability in this model however, and that is during the initial request to the server over HTTP. Using a tool, and this has been proven to work by Moxie Marlinspike, the initial request can be intercepted, the SSL can be stripped off without the user knowing it, and the user redirected to a malicious site instead. In order to mitigate that attack, the initial request must be over HTTPS (technically TLS is used these days on any web server that is up-to-date, but for historical reasons people often still call it SSL which has been deprecated).

To achieve this, the browser has to know ahead of time which sites have implemented HSTS, the strict policy of using HTTPS. That's where the preload list comes into play. Site administrators or owners can register with the HSTS preload list, and that list comes preinstalled on browsers.

This is just like HTTPS Everywhere - it requires site owners to register as well, but that involves writing more complex rules. When a site is registered with HTTPS Everywhere, only then will it load the site over HTTPS.

Eventually, HSTS will likely make the extension obsolete. For the time being there is still the case where sites are serving over the secure protocol, but cannot register with the preload list because they have subdomains that aren't. This issue has to be resolved before HSTS can totally replace the extension, but that is the ideal scenario since HSTS works for everyone, not just people who install an extension.

It's important to point out though, that currently neither method redirects the initial request for all sites that have HTTPS, only those on their respective lists. So just because you're using HTTPS Everywhere, and a site loads over HTTP, doesn't mean that site is unable to serve over HTTPS.

Edits:

* Some sites will just reject insecure traffic coming in on port 80 and fail to load. This is more secure but less friendly. The site looks broken, but if the user makes a new secure request to begin the session, then the sslstrip attack cannot be used.

BoneTone

@MrNoName

Close. This applies to mixed content as you describe (pages that load over HTTPS but some resources on the page load over HTTP), but it's not redirecting users who request a site over HTTP to HTTPS and it works a little different than you describe.

The first change comes in 79, giving users an option to unblock mixed content. Currently some mixed content is already blocked, like scripts & frames. This will let users disable that.

In 80, Chrome will load videos & audio over HTTPS if they are available even when the page has embedded them with HTTP. If they aren't available over HTTPS, then they'll be blocked. Users can disable this with the option mentioned above.

In 81, Chrome will do the same thing to the last resource it doesn't block, images. Load over HTTPS if possible, block if not, give users the option to disable that.

There are changes to the UI (the lock) that accompany these changes to hopefully communicate the safety of the site more clearly to the user.

But in all cases, I believe, if you click a link that is http it'll still load just fine. This is only effecting content loading on the page, not when you click on a link, image or video that will load over HTTP. That isn't mixed content.

madiso

I don't really like HTTPS Everywhere extension's idea - it is essentially just an addition to the HSTS list.

What would be better is to just attempt using HTTPS by default, falling back to HTTP when that fails, similar to the extension Smart HTTPS.

ccurley

HTTPS Everywhere is going away in January 2023. See https://www.eff.org/https-everywhere/set-https-default-your-browser for the gory details.

Will it eventually show up in Vivaldi?

nomadic