With HTTPS Everywhere, EFF Begins Plans to Eventually Deprecate 'HTTPS Everywhere' Extension (therecord.media) 48
The Record reports:
The Electronic Frontier Foundation said it is preparing to retire the famous HTTPS Everywhere browser extension after HTTPS adoption has picked up and after several web browsers have introduced HTTPS-only modes." "After the end of this year, the extension will be in 'maintenance mode' for 2022," said Alexis Hancock, Director of Engineering at the EFF. Maintenance mode means the extension will receive minor bug fixes next year but no new features or further development.
No official end-of-life date has been decided, a date after which no updates will be provided for the extension whatsoever.
Launched in June 2010, the HTTPS Everywhere browser extension is one of the most successful browser extensions ever released. The extension worked by automatically switching web connections from HTTP to HTTPS if websites had an HTTPS option available. At the time it was released, it helped upgrade site connections to HTTPS when users clicked on HTTP links or typed domains in their browser without specifying the "https://" prefix. The extension reached cult status among privacy advocates and was integrated into the Tor Browser and, after that, in many other privacy-conscious browsers. But since 2010, HTTPS is not a fringe technology anymore. Currently, around 86.6% of all internet sites support HTTPS connections. Browser makers such as Chrome and Mozilla previously reported that HTTPS traffic usually accounts for 90% to 95% of their daily connections.
From EFF's announcement: The goal of HTTPS Everywhere was always to become redundant. That would mean we'd achieved our larger goal: a world where HTTPS is so broadly available and accessible that users no longer need an extra browser extension to get it. Now that world is closer than ever, with mainstream browsers offering native support for an HTTPS-only mode.
With these simple settings available, EFF is preparing to deprecate the HTTPS Everywhere web extension as we look to new frontiers of secure protocols like SSL/TLS... We know many different kinds of users have this tool installed, and want to give our partners and users the needed time to transition.
The announcement also promises to inform users of browser-native HTTPS-only options before the day when the extension reaches its final sunsetting — and ends with instructions for how to activate the native HTTPS-only features in Firefox, Chrome, Edge, and Safari, "and celebrate with us that HTTPS is truly everywhere for users."
No official end-of-life date has been decided, a date after which no updates will be provided for the extension whatsoever.
Launched in June 2010, the HTTPS Everywhere browser extension is one of the most successful browser extensions ever released. The extension worked by automatically switching web connections from HTTP to HTTPS if websites had an HTTPS option available. At the time it was released, it helped upgrade site connections to HTTPS when users clicked on HTTP links or typed domains in their browser without specifying the "https://" prefix. The extension reached cult status among privacy advocates and was integrated into the Tor Browser and, after that, in many other privacy-conscious browsers. But since 2010, HTTPS is not a fringe technology anymore. Currently, around 86.6% of all internet sites support HTTPS connections. Browser makers such as Chrome and Mozilla previously reported that HTTPS traffic usually accounts for 90% to 95% of their daily connections.
From EFF's announcement: The goal of HTTPS Everywhere was always to become redundant. That would mean we'd achieved our larger goal: a world where HTTPS is so broadly available and accessible that users no longer need an extra browser extension to get it. Now that world is closer than ever, with mainstream browsers offering native support for an HTTPS-only mode.
With these simple settings available, EFF is preparing to deprecate the HTTPS Everywhere web extension as we look to new frontiers of secure protocols like SSL/TLS... We know many different kinds of users have this tool installed, and want to give our partners and users the needed time to transition.
The announcement also promises to inform users of browser-native HTTPS-only options before the day when the extension reaches its final sunsetting — and ends with instructions for how to activate the native HTTPS-only features in Firefox, Chrome, Edge, and Safari, "and celebrate with us that HTTPS is truly everywhere for users."
Sort out DNSSEC ? (Score:2)
sort out DNS security by implementing DNSSEC - its always DNS is a little tired now...
Re:Sort out DNSSEC ? (Score:5, Interesting)
tl;dr DNSSEC alone still leaks unnecessary information.
domains need to support DNSSEC (Score:2)
providers sure but the source has to be signed...
ESNI Everywhere (Score:2)
Re: (Score:3)
No, they'll just do this: https://www.f5.com/labs/articles/threat-intelligence/kazakhstan-attempts-to-mitm-itscitizens
Browsers have blocked Kazakh interception before (Score:2)
The last few times Kazakhstan issued a root certificate to backdoor all HTTPS connections, such as in fourth quarter 2015 [slashdot.org] and in fourth quarter 2020 [slashdot.org], the major web browser publishers pushed an update to block use of these root certificates.
Re: (Score:2)
I should probably know this, but is it possible for a web server to detect if this sort of MITM has occurred and to reject the connection?
If not, perhaps the specification needs to include this in the future.
Re: (Score:2)
is it possible for a web server to detect if this sort of MITM has occurred and to reject the connection?
To the web server, the MITM box looks like a carrier-grade network address translation (CGNAT) gateway in front of hundreds or thousands of legit clients.
DNS over HTTPS is a hideous abortion (Score:2)
Hopelessly inefficient and slow. The HTTP protocol was not designed for small data packets such as DNS , the overhead in comparison is enormous and given the number of DNS queries made every second its a huge burden on networks everywhere. Not to mention the extra power it takes in the data centre which all adds up.
Really and truly.... (Score:3)
You can count some of your wins in the realm of victory that renders your mission obsolete... ephemeral opposition to your stated goal is yeti/nessie shit.
Re: (Score:2)
Re: (Score:2)
Snowden's Great Success (Score:4, Interesting)
This really was one of the greatest successes in privacy that Snowden's releases got going. Along with Let's Encrypt making it easy and cheap, almost every site out there is HTTPs these days
Re: (Score:1)
What ever happened to simple websites, just plain information, no logins required, no javascript needed, just pure links.
Does everything need to be so appy.
Oh and security is great for IoT hardware, that now needs to be $20 worth of chips, rather than a $1 chip to do HTTPS. Which also cannot ever upgrade its SSL code or its root cert list.
Nothing wrong with http for just reading info/rss etc..
Authenticating the web server to you (Score:2)
What ever happened to simple websites, just plain information, no logins required, no javascript needed, just pure links.
Being able to trust "just plain information" presented on a website requires being able to trust that your browser is connecting to a server operated by the domain owner. HTTPS provides this. Case in point: Though ISPs can and do inject ads into HTML documents delivered over cleartext HTTP, ISPs almost never try that with HTTPS because tampering is so much more visible.
Re: Authenticating the web server to you (Score:2)
Intercepted since day one (Score:2)
HTTP could implement a signing-only mode
I'd be interested to see a patch implementing support for signed cleartext connections in either major web browser engine.
Webmasters could then also apply to have their key fingerprints preloaded in a database
What is the difference between this and Certificate Transparency?
Re: (Score:2)
Re: (Score:3)
Oh and security is great for IoT hardware, that now needs to be $20 worth of chips, rather than a $1 chip to do HTTPS.
If you need $20 worth of chips to do HTTPS then you're doing something very wrong and I suggest you leave the engineering to people who know what they are doing.
Nothing wrong with http for just reading info/rss etc..
It's not up to you to decide if someone else is being persecuted by someone for reading what you wrote.
Re: Snowden's Great Success (Score:1)
Does info come from the expected domain? (Score:3)
For reading information, HTTP is fine.
For reading information and making sure that the information actually comes from the expected domain and not an intercepting proxy, HTTPS is required. You're technically correct that encryption is unnecessary to detect tampering by a proxy. However, HTTPS currently lacks signing-only cipher suites.
Re: (Score:2)
The other issue is that trying to figure out what needs encryption and what doesn't is not trivial, so the safest thing to do is just encrypt everything.
It's a false sense of privacy. (Score:2)
If you think the major world government intelligence agencies have just let the web move to HTTPS while sitting on your hands, you really do have the wool pulled over your eyes.
I guarantee they have access to all of the root certificates and also the private keys for most major web companies. And we know from rooms like 641A that they can MITM anything on demand.
They can decrypt anything they want, and do.
Re: (Score:2)
In practice, they get the data anyway, it's trivial for them to bleed it out of both endpoints. Unless you browse on FreeBSD and don't use social media, I guess. (And your super secret websites don't turn out to be honeypots.)
Everyone who needed HTTPS already used it, without a browser plugin. Except for a few low-effort janky web forums, where you should be using a throwaway password anyway, because you have no idea how they store it on their end.
I suppose it was a success for Google, since it cut ISPs out
Still not everywhere (Score:2)
Huh? (Score:3, Informative)
This is major premature. Unless you are a security nerd and know how to set your preference settings, Chrome 94 (the latest version) defaults to unencrypted HTTP. And yes, that is bad. A lot of people stupidly believe that http is OK when they are visiting some random useless website. But what they do not understand is that an attacker anywhere on the network between your wifi and the website can inject traffic into the http stream. So what? They can inject a browser exploit. A browser exploit can be used to take over your machine remotely, your webcam, monitor and inject whatever onto your computer. Then what are you going to do?
Re:Huh? (Score:4, Interesting)
Chrome has defaulted to HTTPS since version 90, released earlier this year.
Since 2018 Chrome has also been flagging HTTP sites as "not secure" and warning the user if they try to submit a form on such a site.
Re:Huh? (Score:4)
If a browser is so insecure that some arbitrary code can be inserted and gain control of your system, what makes you so sure that an encrypted communication stream will protect you? Sites insert code from other locations on a regular basis even when you are browsing only with encrypted connections. Many players are vying for this position including the 3 main OS providers. This can be seen by the many instances of unscrupulous app developers, including the 3 major OS developers. Microsoft, Apple and Google. Encryption and certification do not resolve the problem. Laws with teeth need to be in place first to hold people and corporations accountable.
If they have the resources to place themselves between my browser and the sites I visit then it's cheaper for them to buy an ad on a site that I do visit to target me than to insert themselves in the middle.
can we fix browsers for local sites now? (Score:2)
Now, can we fix the browsers so that if I go to localhost,
Re:can we fix browsers for local sites now? (Score:4, Informative)
You don't need a publicly routable website. You need only a fully qualified domain name into which you can insert a TXT record for the dns-01 challenge.
Re: (Score:3)
I still wonder how the fuck I'm supposed to run a Let's Encrypt bot on my Ethernet switch, or my Wireless AP, or the embedded device that controls my sprinklers. Stuff like this is why the "SSL All The Things!" people kinda piss me off. There are plenty of perfectly legitimate cases where paid SSL certs are impossible to justify and short-term SSL certs are impossible to manage.
Re: (Score:2)
the end of the open source web.... (Score:1)
It's great, right? No one will be able to Download things from the web unless they have the latest, standards approved ssl lib on their system to access an all encrypted web. Open Source? Have you wondered, at all, about why you need to have a full approved encryption stack to access "open source".
Try using an old enough browser and you find yourself shut out of many open source sites that will upgrade you to https -- but with requirements on it being new enough to talk to the latest ssl suites.
The mirr
Did your ISP substitute malware? (Score:3)
It really is a shame all of the open source sites had to fall for this fudd and didn't keep offering the choice of clear-open-source text along side an encrypted link.
Say you download a GNU/Linux distribution installer image over cleartext HTTP. How can you be sure that your ISP didn't substitute an image full of malware?
Re: (Score:3)
Open Source SW has long been signed. That provides integrity.
Re: (Score:2)
Re: (Score:2, Offtopic)
One day you'll be able to afford to buy a proper keyboard.
Re: (Score:2)
If I'm downloading install images, most installers allow the signing of the image, and, perhaps the binary. The integrity check is builtin to the installer and requires extra steps to avoid. Examples include install images in the RPM (RedHat/Suse, et al) format, among others.
Besides, I have not suggested disabling https but NOT disabling 'http', which is what the current methods do.
Re: (Score:2)
Examples include install images in the RPM (RedHat/Suse, et al) format, among others.
You would still need to obtain and provide a fingerprint of the publisher's public key when installing the package manager (dnf, apt, pacman, etc.) for the first time, such as when installing an operating system distribution from a USB drive image. How would these fingerprints be securely distributed?
Re: (Score:2)
They could be distributed the same way the keys for the https system distributes keys. The publisher would get a signing key that can be used to sign code in addition to signing secure web traffic. They can be exactly the same type of key.
Encryption keys allow specification of how they can be used when they are issued. No reason why such a key couldn't be used to sign code as well as web traffic.
Code signing has historically required OV cert (Score:2)
No reason why such a key couldn't be used to sign code as well as web traffic.
Publishers of major desktop computer operating systems have behaved as if there is some reason or excuse to insist that code signing certificates provide at least "organization validated" level of assurance (in the DV vs. OV vs. EV sense). I don't know what this reason or excuse is. I guess it might have something to do with compromise of a download server having longer-lasting consequences for users than compromise of an interactive web application server, or the fact that major desktop operating systems d
Re: (Score:2)
Good point.
The current practices mean that certs used to verify integrity on downloaded sources that are using 'https' as certification that there has been no code tampering are using the lower level (w.r.t DV/OV/EV) of certification and skirting requirements that might be applied to the code-certification usage of a certificate.
In other words the lower-requirement web-traffic signing certs are being misused to verify code integrity, whereas real code integrity certs might require a higher internal verific
Older Servers? (Score:1)
That means my 30 year old HP3000 website running Apache 1.2 may not run in your browser.
empire.game-host.org
(The site may be down due to a neighborhood Verizon outage, been a week, check again tomorrow.)