Firefox 127.0 released [LWN.net]

Everything old is new again

Posted Jun 12, 2024 1:07 UTC (Wed) by flussence (guest, #85566) [Link] (6 responses)

Remember when Mozilla Suite had a preloader systray icon because it took a while to start up on machines a thousand times less powerful than today's phones? Something must be going disastrously wrong in Microsoft land for them to have to bring it back for that platform only.

> Setting Firefox to auto-launch optimizes efficiency in our browser-centric digital routines
wtf?

Everything old is new again

Posted Jun 12, 2024 1:57 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I know people who have hundreds of simultaneously open tabs.

Everything old is new again

Posted Jun 12, 2024 8:30 UTC (Wed) by leromarinvit (subscriber, #56850) [Link]

Counting 3100 spread over 5 windows currently. Firefox takes maybe 5 seconds to launch and restore these windows on a box that's probably at least 5 years old (not all tabs of course, they're loaded when accessed).

I'm not a huge fan of everything Mozilla has changed in Firefox in the past few years, and it does have its warts. But startup performance is honestly not one I've ever noticed.

Everything old is new again

Posted Jun 12, 2024 2:07 UTC (Wed) by roc (subscriber, #30627) [Link] (2 responses)

A lot of people, maybe most people, always open the browser on startup to check their email or whatever.

Everything old is new again

Posted Jun 12, 2024 13:42 UTC (Wed) by eduperez (guest, #11232) [Link] (1 responses)

Some companies have based their workflow on web-centric applications; in my daily job, the web browser is almost the desktop, because every app I launch is a web page.

Everything old is new again

Posted Jun 12, 2024 14:54 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Oh, that was the "royal our", not "our (as in Mozilla)"… First person usage in release notes feels weird and this is a wonderful example of why.

Everything old is new again

Posted Jun 13, 2024 1:43 UTC (Thu) by barryn (subscriber, #5996) [Link]

Microsoft Edge has had a similar feature (but without the visible systray icon) called "Startup Boost" for a few years now, enabled by default. I guess the Firefox devs feel that Firefox needs to compete better against Edge on this front.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 12, 2024 10:10 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (30 responses)

I use the Firefox HTTPS-only mode for a few years now, it prompts you if an entire site isn't available in HTTPS and you get to it via an http URL (which it would otherwise silently upgrade) and I find that I see maybe 2-3 such prompts each week, for maybe somebody's archaic blog or other site. I think this might be a reasonable default (given the ability to accept the prompt) for most technical people who have some idea what HTTPS is, but it's not yet quite OK to give my mother.

All the sites which weren't HTTPS enabled "on principle" are gone, either abandoned or upgraded to HTTPS - so it's now just outdated stragglers.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 12, 2024 11:41 UTC (Wed) by eru (subscriber, #2753) [Link] (29 responses)

Some company intranet sites in my workplace are just http, and that makes sense. Setting up https is too much hassle for these mini sites that only provide some piece of local info, and having the browser complain about "insecure site" is annoying.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 12, 2024 11:55 UTC (Wed) by dskoll (subscriber, #1630) [Link] (23 responses)

No, I don't think it makes sense any more. Getting a LetsEncrypt wildcard certificate is very easy; it's set-and-forget nowadays. You never know when one of these little HTTP-only internal sites is going to add a password-protected section, and even on a corporate LAN you shouldn't be transmitting credentials in the clear.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 12, 2024 12:05 UTC (Wed) by jch (guest, #51929) [Link] (18 responses)

> Getting a LetsEncrypt wildcard certificate is very easy; it's set-and-forget nowadays.

Only if your website that has unrestricted access to the Internet. Which is not necessarily the case of many internal services.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 12, 2024 12:23 UTC (Wed) by dskoll (subscriber, #1630) [Link] (17 responses)

Actually, no, the web site does not need unrestricted access to the Internet for a wildcard certificate. You need one machine that can run acme-dns to obtain the certificate. Once the certificate is obtained, it can be distributed to internal machines however you like.

In my case, I have a machine with access to the Internet that gets the certificate, and it then rsyncs it to all of the internal machines that require it.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 12, 2024 14:06 UTC (Wed) by jch (guest, #51929) [Link] (16 responses)

> Actually, no, the web site does not need unrestricted access to the Internet for a wildcard certificate.

That's only true if your network administrator agrees to give out wildcard certificates. (Or if you have a dedicated domain just for yourself.)

But your point stands: workarounds do exist, and we do manage, at the end of the day, to have a proper certificate on every server. However, none of this hassle would be necessary if the browser vendors had implemented unauthentified TLS.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 12, 2024 22:30 UTC (Wed) by dskoll (subscriber, #1630) [Link] (15 responses)

Yeah, I mentioned wildcard certs right from the start because those are much easier to manage, as long as all your hosts are named something.yourdomain.example. And yes, it does require buy-in from the network admin, but I would expect that in a given organization, the network admin would not try to obstruct things that can help the organization. :)

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 8:43 UTC (Thu) by kleptog (subscriber, #1183) [Link] (8 responses)

How would that work? The network admin maintains a wildcard cert+key on some public server on the intranet so all the different servers can download it and use it? That sounds like a completely different kind of security nightmare.

We have a portal where you can submit CSRs and some admin needs to approve it. It's kind of OK, but you really don't want too short expiry periods or you literally spend a significant chunk of your time renewing certificates. Many of the machines are not in DNS or publicly accessible so automation is tricky. Something like authentication via proving you have access to the old private key would work, but I can't see anything like that in ACME (probably for good reasons).

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 13:28 UTC (Thu) by dskoll (subscriber, #1630) [Link] (7 responses)

No, each time the cert needs to be updated, the network admin would rsync the wildcard cert to specific servers via SSH. The network admin would have a private SSH key with enough permission to do this on the internal machines, and the network admin would only SSH the key to specific machines that have been vetted and whose SSH keys are known. The internal machines don't need to be externally resolvable, or even have Internet access at all. This is what I do for my machines.

You probably also want to use an internal domain such as *.intranet.realdomain.example or *.completely-different.example for internal machines rather than your real public-facing domain if you are worried about someone obtaining a copy of the certificate. That somewhat limits the damage they can do.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 17:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

> No, each time the cert needs to be updated, the network admin would rsync the wildcard cert to specific servers via SSH.

A lot of services read the certificate once during startup, so you also need to restart them. Then you also have services that store the certificate in some kind of a database. And dockerized services that might need an image rebuild.

It's really not that easy. For my home network, I just bought a 5-year wildcard certificate for $100, so I don't need to worry about rekeying everything. But that's really not a lot of security.

I wish SSL were hierarchical, so that I could sign my own subcertificates for individual domain names. Sigh.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 18:14 UTC (Thu) by farnz (subscriber, #17727) [Link] (3 responses)

I'd love it to be possible for LetsEncrypt to sign my private CA for 30 days, conditional on my CA only issuing certificates for my domain names (as verified by LE), while allowing my CA to be valid for 20 years.

The idea is that anyone who trusts LE only trusts certs I've issued (or my CA) for 30 days after the LE signature, but if I can persuade you to import my private CA cert, you trust certificates I issue until their expiry date (or my CA's validity date, whichever comes first).

The other thing I'd like in X.509 is the ability to have multiple chains from a certificate to a CA; it'd be nice to be able to have a single certificate that was verified via the LE chain (for public visitors), and verified via my private CA (so that I trust it even when the LE signature has expired, making it easier to replace the LE chain every 30 days).

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 19:47 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

This technically can be expressed in today's X509!

You use your private infrastructure to sign certs, and specify the URI of your CA in: "Authority Information Access - CA Issuers - URI" extension field. Then this URL can return a certificate that is signed by the Let's Encrypt CA. You simply update this certificate once the signature expires. And your CA is in turn limited to your domain via the "Name Constraints" ( https://datatracker.ietf.org/doc/html/rfc5280#page-40 ) extension.

Now to bad news: name constraints fail open. This makes them a non-starter for any realistic applications. They must be redesigned to fail-closed, if a library doesn't understand them, the certificate validation should fail.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 22:19 UTC (Thu) by intgr (subscriber, #39733) [Link] (1 responses)

> name constraints fail open. This makes them a non-starter for any realistic applications.

I believe this is not correct. Every extension (such as Name Constraints) in a cert has a boolean flag called "critical".

Non-critical extensions may be ignored by implementations if they are not recognized (fail open). But the presence of unrecognized critical extensions will make the cert immediately invalid (fail closed).

It's up to the parent CA to mark the constraints as critical.

Of course there may be implementations that interpret Name Constraints incorrectly but that's another matter.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 22:41 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

I've seen X509 implementations that ignore critical extensions (or even things like SANs).

Proper modern implementation of restrictions would need to include something that poisons certificate validation for incorrect implementations.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 15, 2024 2:20 UTC (Sat) by dskoll (subscriber, #1630) [Link]

A lot of services read the certificate once during startup, so you also need to restart them

Yup, that's also scripted. It's a bit of a pain to set up, but once it's set up, it just runs on its own. Basically, each machine has a script that knows how to reload relevant services if a certificate has been updated; the sync script runs that script iff the cert has actually been updated.

And dockerized services that might need an image rebuild.

"Doctor, it hurts when I do that!" "Then don't do that!"

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 15, 2024 3:24 UTC (Sat) by intelfx (subscriber, #130118) [Link]

> And dockerized services that might need an image rebuild.

Huh?

Please don't tell me you're baking secrets into docker images?

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 11:57 UTC (Thu) by jch (guest, #51929) [Link] (5 responses)

> wildcard certs [...] require buy-in from the network admin

The network admins are quite friendly, but while they're quite willing to trust me with a certificate for seminar-reservations.amediumsizeuniversity.fr, they're not going to give me a certificate that would allow an attacker to impersonate www.amediumsizeuniversity.fr. Go figure. Perhaps they don't trust my sysadmin skills?

I've already said it, but I'll keep repeating myself until corbet himself steps down from his throne and tells me to shut up: the opposition of the browser developers to unauthentified TLS costs us countless hours of pointless hassle.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 12:36 UTC (Thu) by mbunkus (subscriber, #87248) [Link] (4 responses)

Use sub-domains: *.it-department.myimaginarycompany.de Or even use something your official domain is not a suffix of.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 16:10 UTC (Thu) by mikebenden (guest, #74702) [Link] (2 responses)

> Use sub-domains: *.it-department.myimaginarycompany.de Or even use something your official domain is not a suffix of.

Yeah, but now you're just reinforcing jch's point: I have a box serving static content (file downloads, replacing ye olde ftp server) for public unauthenticated access.

I don't need, nor do I want, the hassle of having to ssl/https-ify this box just because browser developers decided, in their wisdom, that their users are too dumb to be trusted to access plain unauthenticated http web sites :)

This situation is getting hilariously stupid. If my browser starts dictaging policy to me, and I can't disable that "feature" (because in practice it's WAY too much hassle to patch out undesireable behavior from a browser), then it's free/open source in name only ("de jure", fine, OK, but no longer "de facto")...

That, in a nutshell, is why we need a third party browser, one that respects the idea that really Free software ought to side with its *user*, not enforce some overbearing idea of "developer knows best", through either closed source or through the sheer PITA that is rebuilding currently available open source with all this crap edited out...

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 17:02 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (1 responses)

Really, if providing HTTPS is a "hassle" to you, you are doing sysadmining wrong.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 17:10 UTC (Thu) by mikebenden (guest, #74702) [Link]

> Really, if providing HTTPS is a "hassle" to you, you are doing sysadmining wrong.

So, is "adding unnecessary external dependencies" part of your "doing sysadmining right" philosophy? Good to know, that explains a few things I've been wondering about lately... :)

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 14, 2024 9:40 UTC (Fri) by jch (guest, #51929) [Link]

> Use sub-domains: *.it-department.myimaginarycompany.de Or even use something your official domain is not a suffix of.

Yes, as said before, workaround do exist. But that's not the point.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 12, 2024 12:41 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (3 responses)

Or better, get a TLS certificate signed by your internal CA. Some CA implementation provide ACME support, and `cert-manager` can also speak other provider's protocols.

There is no excuse for missing HTTPS even on internal sites.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 12, 2024 14:57 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

Alas, when the certificate expires and can only be updated via the web management interface, accessing your NAS when Firefox says "but it looks insecure" is an exercise in frustration. Luckily I use FreeNAS where one *can* just go and poke the backing database…

TLS certificates and embedded systems

Posted Jun 12, 2024 18:59 UTC (Wed) by DemiMarie (subscriber, #164188) [Link] (1 responses)

Then use a reverse proxy where the certificate can be reasonably updated.

TLS certificates and embedded systems

Posted Jun 12, 2024 20:03 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Probably could do that *now*, but there was a chicken-egg problem where the NAS was configured to redirect to HTTPS; I suspect any reverse proxy would have been told to stuff it when it tried to do the proxying too. In any case, I *do* have access to a wildcard certificate in this case and can use it. But figuring out how to get there was an interesting spelunk and hoping my SQL command did what I thought it should do.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 12, 2024 12:02 UTC (Wed) by jch (guest, #51929) [Link]

> Setting up https is too much hassle for these mini sites that only provide some piece of local info, and having the browser complain about "insecure site" is annoying.

There's and old argument that browsers should allow unauthenticated TLS ("better than nothing security"), which effectively protects against passive monitoring without incurring the hassle of setting up (and periodically renewing) certifficates.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 12, 2024 12:11 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

For a smaller employer (I currently work for a Russell Group university so, not us) I can see that it was inconvenient to do this with for-profit CAs even with some sort of agreed bulk purchase arrangement. But, Let's Encrypt was opened to the public almost a decade ago - I no longer see "But it was easier not to" as a sign of anything other than an outdated technology stack, it's like having telnet open in 2005. Sure, ten years ago this was a hard problem, but it got solved and it's about time you caught up to that.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 12, 2024 13:44 UTC (Wed) by eduperez (guest, #11232) [Link] (1 responses)

Even if the information is irrelevant to outsiders, and even if the intranet cannot be accessed from outside, the credentials travel unencrypted; a rogue employee could gain access to the credentials from other users, and use those credentials on other internal systems.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 10:05 UTC (Thu) by eru (subscriber, #2753) [Link]

Usually these kinds of intranet mini sites do not use authentication. They are just for distributing some information in a convenient way.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 5:44 UTC (Thu) by ceplm (subscriber, #41334) [Link]

Just click on the broken lock icon and mark the whole website as HTTP-only.

Can this be turned off?

Posted Jun 14, 2024 22:29 UTC (Fri) by jschrod (subscriber, #1646) [Link] (2 responses)

The most important question hasn't been answered: can this be turned off for a domain?

While I see the value for Internet communication, I want to be able to turn it off for communication during development - where sometimes I have to use Wireshark, and then HTTP is a bonus.

Can this be turned off?

Posted Jun 15, 2024 14:13 UTC (Sat) by dskoll (subscriber, #1630) [Link] (1 responses)

Yeah, for debugging, HTTP can be handy. So I hope / assume Mozilla will still make it possible to use plain HTTP.

Can this be turned off?

Posted Jun 16, 2024 6:40 UTC (Sun) by Wol (subscriber, #4433) [Link]

What about all those old devices (web-managed printers for example) that don't "do" https?

Cheers,
Wol