In an alternative timeline, Firefox makes their context menu really short and someone writes a blog post ranting about how it deprives functionality from power users.
In fact, I've read several such rants about Firefox removing functionality from other parts of their UI.
I really wish they'd just make it easily customizable. I don't care if lay-users might mess it up and get confused, such users abandoned Firefox years ago anyway.
Not a UX designer, but having supported systems for decades I don't agree with your statement. If you got the system down to a single button that said 'Do' the user would still somehow screw it up.
Honestly, "go into about:config and flip some switches to remove stuff" is about as easy as I could imagine for allowing people to customize it. What would you suggest?
Yeah, if you turn it all into buttons and settings in the actual settings menus, someone else is going to post a long rant about how the settings menus have a million confusing options that nobody uses...
Mine also isn't anywhere nearly as confusing as his by default, so this smells like a power-user-has-power-user-problems-and-solutions rant...
They intentionally made the menu longer to look worse by selecting some text first. So it is showing four sets of contextual actions: For the Link, the Image, the Selection, and the Page.
Also a few of the menu items are new since the latest ESR (the AI stuff in particular), so you won't see them if you are running v140.
I'd suggest that they make it clearer what the user actually changed, in about:config, and show the defaults. If I click that button "Show only modified settings" I see a lot of things, mostly options that I set from the normal settings. I mean "browser.download.lastDir" should be in practically everyone's.
So there's a lot of noise and resetting things can be unclear. Especially given that when you reinstall things not all uninstalls clear out settings. It could definitely help if the about:config page tells you about the user.js file and directs you to more information. Why doesn't editing things in about:config generate the user.js file? Maybe tell people about prefer.js and where it exists?
The other thing I'd suggest, documentation. Like what is "browser.translations.chaos.errors"? There's a million things like that that are hard to learn about and explore. In an ideal system there would be a wiki with every option documented and when hovering over the option you'd get a short explanation and a click is a link to the documentation. But that's also a big undertaking (if you're building a new browser, would be nice to do this from the get go!)
I don't think there's a perfect solution and certainly these things are not easy to implement, but if you're asking how it could be easier for the user, then yeah, I think these things would be major improvements and help prevent the blindly following of random blog posts and copy pasting of things like betterfox (I'm sure it is, but how do I know?)
> In an ideal system there would be a wiki with every option documented and when hovering over the option you'd get a short explanation and a click is a link to the documentation.
doesn't even need to be a wiki, because programs should contain their own help files! Like how commandline programs are encouraged (by command arg parsing libraries) to include the documentation in the very code that parses it.
Whoever that added those config option should also document it, preferably right in the code so that automatic generation of docs for the UI is possible (and ensures that it matches the version you're using).
The toolbar has a "Customize toolbar" GUI screen that lets you add, remove and reorder elements. Maybe something similar could be done for context menus, including new entries added by extensions.
there is a middle ground where you could do something like about:mouse (about:keyboard for keyboard shortcuts already exists) for the power users. doesn't need to be fancy but it would be easy enough to do.
Mozilla should really try taking their extension ecosystem seriously, and deliver features like the AI chatbot integration as first-party extensions that come pre-installed but can be easily managed by users with a much better UI than about:config.
And then people would complain about Firefox being bloated with all these built-in extensions. And then if you don't pre-install them people will complain about needing to add all of these extra extensions.
Kinda, but if something can be built as an extension, it probably should be. It proves what you can do with the APIs, proves it can be replaced / forked by other people, and ensures a consistent level of isolation by default.
And if it can't... often it's worth asking if it should be possible.
There would still be decidedly fewer complaints, because extensions are vastly easier to manage and disable or remove than this long list of about:config settings. The fact that you cannot satisfy everybody simultaneously cannot be an excuse for failing to ship with sensible defaults and easy, discoverable customization.
Indeed, and this argument ("it will be too bloated") is often used by developers themselves to avoid (or hide) advanced features. I never quite understood it. Just put all the mysterious flags behind an "Advanced" menu, which normie users will know not to touch.
They right clicked on an image which is also a clickable link which adds the additional options for both links and images, a total of 11, to the defaults.
Yes, that's one of the things that really should have been an extension. Tree Style Tab works alright as an extension-provided sidebar.
Putting the chat or sidebar in the core of the browser sounds very much like something done by a developer who wasn't around for Mozilla prior to Firefox, and isn't aware of the original goal of being the antithesis of the browser that included everything and the kitchen sink.
I definitely think this is a hard task and it's pretty apparent with Firefox. I mean no matter what they do people are going to be very vocal and upset about it.
But to talk more generally, I think finding the balance of what options to expose to normal users and then how to expose things to power users is quite challenging. I think a big mistake people make is to just ignore power users and act like that just because they're a small percentage of users that they aren't important[0].
I think what makes computers so successful is the fact that computers aren't really a product designed "for everyone," instead, they're built as environments that can be turned into a thing that anyone needs. Which is why your power users become important and in a way, why this balance is hard to strike because in some sense every user is a power user. Nobody has the same programs installed on their computers, nobody has the same apps installed on their phones, each and every device is unique. You give them the power to make it their own, and that's the only way you can truly build something that works for everyone.
This is why I think computers are magic! But I think we've lost this idea. We've been regressing to the mean. The problem is when you create something for everybody you end up making something for nobody.
[0] I think Jack Conte (Patreon/Pomplamoose) explains it well here. It's the subset that is passionate that are often your greatest ally. No matter what you sell, most of the money comes from a small subset of buyers. The same is true with whatever metric we look at. As a musician a small subset of listeners are the ones that introduce you to the most people, buy the most merch, and all that that makes you successful. It's not the average "user" but the "power user". https://www.youtube.com/watch?v=5zUndMfMInc
At 13:00 he quotes Kevin Kelly (founder of Wired) and I think it captures the thesis of this talk
In the age of the internet, you don't need millions of fans to be successful. If you can just find 1000 people who are willing to buy $100 of stuff from you per year, that's $100k/yr.
It's about the disrespect of not asking. Could Firefox have asked if users wanted to enable AI features? Of course they could have, did they? Of course not, just think about how would asking would effect the shareholders!!
I don't disagree with the premise that it's hard to make everyone happy, but the problem isn't about pleasing everyone, it's about treating users with respect, and not jumping on the AI everywhere bandwagon, without asking first. Especially because Firefox has billed itself as privacy protecting, and AI is definitely not privacy focused. One might even say, privacy violating... From the privacy focused browser...
Could they have asked me if I wanted to enable 100 different browser features? Yes they could have, but why would they b/c that's incredibly annoying. If you don't like it you don't have to use it. The AI option doesn't send anything to the server unless you explicitly tell it to, so that is 100% compatible with a privacy focused browser.
The blog post is also complaining about the options to create a screenshot, copy a link to a text fragment, copy a link without trackers, debug accessibility issues, auto-fill a form, and even to print the page.
Also, Mozilla Corporation's sole "shareholder" is the not-for-profit Mozilla Foundation.
Also consistency. I personally hate entries appearing and disappearing (e.g. "copy clean link"), I would much rather have a stable UI with disabled elements if something is sometimes relevant to invisible context (like href attributes).
Otherwise you get "where is X? It was here yesterday!" issues, and those are practically impossible to figure out if you don't already know why it behaves that way. At least a disabled entry tells you "this exists, it just isn't applicable" rather than "lol what? maybe we removed it".
Completely useless. Thanks for showing me every feature you’ve ever shipped
And that's what it is, we'll just use the right-click menu as a garbage dump for every feature we've added. I've currently got my right-click menu down to eight entries, of which four are extensions I added (NoScript, DownThemAll, etc), and the four built-in ones are things I've never, ever used in 20+ years as a Firefox user. I'm also running RightLinks which turns right clicks on a link into "Open in New Tab", which is what I want to do, oh, approximately 100% of the time I right-click on a link (for the epsilon times I don't want to do that you can override with Ctrl-Click to get the original menu back). Its actually painful watching users who haven't overridden the Firefox builtins use right-click, "right-click, scroll, scroll, pause to check, scroll, click".
I don't know what I've done to have a small right click menu but mine is only a handful of options and I even tried selecting an image and a link and some text to get all the options.
It had one fixed menu entry called "advanced menu" this replaces the menu with one that has everything (except from "advanced menu" which is replaced with "simple menu").
One of the menu entries is "configure simple menu". This opens the same looking menu as "advanced menu" only clicking any functionality toggles a check mark in front of it.
If a sub menu had less than 3 options it is merged into the parent menu.
One plays with it for a bit and before long it becomes a Japanese celebration of emptiness.
It even had a bunch of sort of redundant options. The sms submenu had something like 8 options of which I only really used "new message" and "all messages" but you could go for "unread messages". It's not like the rest of the menu is gone, its all under "advanced menu".
If the right click menu worked like that some would bother to further configure the simple menu and one could share their config.
To make it clear it is not a "more" button "advanced" could fold out the hidden entries like a harmonica.
It's the duality of user interface design. Two forces at war with each other.
The professional interface is a complete mess. flat not nested, functionality duplicated all over the place, widgets strewn across the screen like a toddler just got done playing legos. Exactly what one needs when they will be working with it for hours at end.
Contrast with the casual interface, nested, one way to do things, neat compartments for everything. What is needed to gently guide the user through an unfamiliar task they may only do once a year.
And this is ignoring the dark side, the "designer" interface. Where it just has look good functionality be damned. Take note. The big lie about design is that it exists in a vacuum, that there can be an independent design title. Real design is fundamentally a holistic process that has to consider and integrate all aspects. Including deep engineering. A real designer is an engineer with taste, a rare find to be sure.
> The professional interface is a complete mess. flat not nested, functionality duplicated all over the place, widgets strewn across the screen like a toddler just got done playing legos. Exactly what one needs when they will be working with it for hours at end.
It's flat (technically modal, but that does not make it more casual) interface with everything as invisible hotkeys and a near command line interface (the legos all over the place, actually in this case a better analogy would be legos all over the place under water in a bathtub)
The trick is adding letter selections so you can press the underlined letter on your keyboard and get that option! You can do things really quickly that way!
How about Firefox just not fill their context menu with bullshit bloat and ads for shit nobody asked for like google lens and make it fully/easily customizable so that most users are happy and power users can add whatever they want.
It literally already is fully customizable. between userChrome, about:config, and extensions, you can do literally anything you like to your right click menu on Firefox.
I'd argue that you shouldn't need third party add-ons plus modifications to both userChrome and about:config to do it, so it could be easier. A "Customize Context Menu" under Edit would be nice and easy for even regular users to discover and take advantage of.
Why is my Edit menu so long? What is this "Customize Context Menu" thing that I never use, or will use at most once a year?
Just kidding, but it does illustrate that there's always a tradeoff with these things. (I would like to have the ability to customize the context menu too, fwiw, though it's not as straightforward as the other customizable bits of UI since the context menu is, well, contextual.)
about:config where you need a search engine to find all the key strings does not count as easy in this context. And it's unreasonable to pretend it is.
> How about Firefox just not fill their context menu with bullshit bloat and ads for shit nobody asked for like google lens and [...] It's pretty damn easy to make everyone happy
This is the same mistake they made with Pocket and I'm guessing it was done for the same reason (money) since they went with a Google product and not Bing Visual Search or for that matter letting users configure what service they'd like to use for image searches. This was pure bloat. It's no different from Windows adding candy crush to the desktop by default where the same argument "Some people play it and it can be removed!" does nothing to change what it is: bloat that nobody asked for.
At the beginning of a TCP connection, which is when the certificate chain is sent, you can't send more data than the initial congestion window without waiting for it to be acknowledged. 160KB is far beyond the initial congestion window, so on a high-latency connection the additional time would be higher than the numbers you calculated. Of course, if the web page is very bloated the user might not notice, but not all pages are bloated.
The increased certificate size would also be painful for Certificate Transparency logs, which are required to store certificates and transmit them to anyone who asks. MTC doesn't require logs to store the subject public key.
That is exactly the type of poor design that I was saying should be rectified.
You can already configure your initial congestion window, and if you are connecting to a system expecting the use of PQ encryption, you should set your initial congestion window to be large enough for the certificate; doing otherwise is height of incompetence and should be fixed.
You could also use better protocols like QUIC which has a independently flow controlled crypto stream and you can avoid amplification attacks by pre-sending adequate amounts of data to stop amplification prevention from activating.
And I fail to see how going from 4 KB of certificate chain to 160 KB of certificate chain poses a serious storage or transmission problem. You can fit literal millions into RAM on reasonable servers. You can fit literal billions into storage on reasonable servers. Sure, if you exactly right-sized your CT servers you might need to upgrade them, but the absolute amount of resources you need for this is miniscule.
Your failure to see the problem doesn’t mean it doesn’t exist. 40x the size might not really be an issue for the hypothetical server you’ve suggested - but that isn’t the reality for the world. Many devices do HTTPS and TLS.
Not to mention the issue is more with the clients.
CT logs would get a lot harder to run (and they’re already not so easy).
> You can already configure your initial congestion window, and if you are connecting to a system expecting the use of PQ encryption, you should set your initial congestion window to be large enough for the certificate; doing otherwise is height of incompetence and should be fixed.
The aggressive tone is no defense against practical problems such as the poor scalability of such a solution.
> You could also use better protocols like QUIC which has a independently flow controlled crypto stream and you can avoid amplification attacks by pre-sending adequate amounts of data to stop amplification prevention from activating.
Not before key exchange it doesn't. There's no magic bullet here.
A refresher on the state of TFO and QUIC PMTU might be worthwhile here before jumping this far ahead.
You have asserted without evidence that the increased certificate chain size is the primary scaling bottleneck. I assert that the bottleneck is most likely due to accidental complexity elsewhere on the argument that claimed problems look to be far in excess of the essential complexity.
> Not before key exchange it doesn't. There's no magic bullet here.
I was incorrect. Rereading the QUIC standard I see that they do not flow control the CRYPTO packet number space/stream. I thought they did because it is so easy to do that I did it as a afterthought. Truly another example of fundamental design errors introducing accidental complexity that should be fixed instead of papered over.
Can you elaborate a bit more about what you think the unnecessary complexity here?
A basic source of concern here is whether it's safe for the server to use an initial congestion window large enough to handle the entire PQ certificate chain without having an unacceptable risk of congestion collapse or other negative consequences. This is a fairly complicated question of network dynamics and the interaction of a bunch of different potentially machines sharing the same network resources, and is largely independent of the network protocol in use (QUIC versus TCP). It's possible that IW20 (or whatever) is fine, but it may well may not be.
There are two secondary issues:
1. Whether the certificate chain is consuming an unacceptable fraction of total bandwidth. I agree that this is less likely for many network flows, but as noted above, there are some flows where it is a large fraction of the total.
2. Potential additional latency introduced by packet loss and the necessary round trip. Every additional packet increases the chance of one of them being lost and you
need the entire certificate chain.
It seems you disagree about the importance of these issues, which is an understandable position, but where you're losing me is that you seem to be attributing this to the design of the protocols we're using. Can you explain further how you think (for instance) QUIC could be different that would ameliorate these issues?
For point 1, as I noted here [1], total bandwidth and resources are dominated by large flows. Endpoints are powerful enough to handle these large flows. The primary problems would lie with poor intervening networks and setup overhead.
For point 2, that is a valid concern of any case where you have just plain old more data. This dovetails into my actual point.
The problem of going from a 4 KB certificate chain to a 16 KB certificate chain, 160 KB certificate chain, or any arbitrary sized certificate chain should be equivalent to the problem of "server sends N byte response like normal". To simplify the problem a little it is just: the client sends a R-byte request message, the server responds with the Q-byte response message (which happens to be a certificate chain), the client sends the P-byte actual request, the server responds with a K-byte response message. So, at the risk of over-simplification, the problem should only be marginally harder than any generic "time to Q + K bytes".
Of course, if you previously had a 4 KB actual response and a 4 KB certificate chain and now it is a 160 KB certificate chain, you are going from "time to 8 KB" to "time to 164 KB". That is the essential complexity to the problem. But as I noted in my response to your point 1, the amount of server and client resources actually being expended on "small" requests is small with only poor networks where you are now consuming significantly increased bandwidth being a problem.
This then leads into the question of why "time to 8 KB" versus "time to 164 KB" is viewed as such a dramatic difference. This is a artifact of poor protocol design.
From a network perspective, the things that mostly matter are end-to-end bandwidth, end-to-end latency, endpoint receive buffer size, and per-hop bandwidth/buffering. You have a transport channel with unknown, dynamic bandwidth and unknown latency and your protocol attempts to discover the true transport channel parameters. Furthermore, excessive usage degrades overall network performance, so you want to avoid over-saturating the network during your discovery. In a ideal world, you would infer the transport parameters of every hop along your path to determine your holistic end-to-end transport channel parameters. This is problematic due to paths shifting or just plain dynamic throttling, so you will probably only limit yourself to "client to common bottleneck (e.g. your router) path" and "common bottleneck to server path". The "client to common bottleneck path" is likely client controlled and can be safely divided and allocated by the client. The "common bottleneck to server path" is not efficiently controllable by the client so requires safe discovery/inference.
The "initial congestion window" is a initial bandwidth-delay product to avoid over-saturating the network. This does not directly map to the transport parameters that matter. What you actually want is a initial safe "end-to-end bandwidth" which you refine via the discovery process. The latency of your roundtrip then only matters if the endpoint receive buffer size is too small and only effects how quickly you can refine/increase the computed safe "end-to-end" bandwidth.
Under the assumption that a 16 KB "initial congestion window" is fine and we assume the default RTT is ~100 ms (a somewhat reasonable assumption for geographically distributed servers who want to minimize latency) then that is actually a initial safe "end-to-end bandwidth" assumption of (16 KB / 0.1 s * 8 B/b) = ~1.3 Mb/s. Assuming the client advertises a receive buffer large enough for the entire certificate chain (which it absolutely should) and there are no packet losses, the client would get the entire certificate chain in ~(1 s + RTT) in the worst case. Note how that has only a minor dependency on the end-to-end latency. Of course it could get the data sooner if the bandwidth gets refined to a higher number, and a lower RTT gives more opportunities to get refined to a higher number, but that bounds our worst case (assuming no packet loss) to something that is not really that bad especially for the poor network throughput that we are assuming.
This then makes it obvious how to improve this scheme by choosing better initial estimates of "end-to-end" bandwidth or actively communicating that information back and forth. The "client to common bottleneck path" can be "controlled" by the client, so it can allocate bandwidth amongst all of its connections and it can set aside bandwidth on that leg for receiving. This allows higher initial "end-to-end" bandwidth assumptions that can be safely clipped when the client realizes it is in bad network conditions such as plane wifi. If the server determines "I have set aside N b/s to the 'internet' for this client" and the client determines "I have set aside M b/s from the 'internet' for this server" then your only problem is if there is a bottleneck in the broader backbone connections between the server and client. You would almost certainly be able to support better initial bandwidth assumptions or at least faster convergence after first RTT if you communicated that information both ways. This is just a example of what and how things could be improved with fairly minimal changes.
And this all assumes that we are even trying to tackle this fairly fundamental root issue rather than what are probably heaps of other forms of accidental complexity like middleboxes just giving up if the certificates are too large or whatever else nonsense there is which is what I am pretty sure is the real impetus by why they want the networking equivalent of wanting the 737-MAX to handle the same as a 737.
A few points of technical clarification might help here.
1. The reason for a relatively small initial congestion window (cwnd) is to avoid situations where a lot of connections start up and collectively exceed the capacity of the network, causing congestion collapse. Instead, you start slow and then gradually ramp up, as you learn the available capacity. Slow start started in TCP but it's in QUIC too. Initial windows actually used to be a lot smaller and TCP only moved up to its current 10 packet initial window (IW10) after a bunch of experimentation that determined it was safe.
2. The congestion window is actually a property of the sender, not the receiver. The receiver advertises the size of their flow control window, but that's about the buffer, not the sending rate (see section 7 of RFC 9002 for the discussion of slow start in QUIC). So in this case, the server controls cwnd, no matter what the client advertises (though the server isn't allowed to exceed the client's advertised flow control window).
3. QUIC and TCP behave fairly similarly in terms of the broad strokes of rate control. As I noted above, QUIC also uses Slow Start. The amplification limit you mention is a separate limit from initial cwnd, which is intended to avoid blind amplification attacks, because, unlike TCP, QUIC servers can start sending data immediately upon receiving the first packet, so you don't know that the IP address wasn't forged. However, even if the peer's IP is authenticated, that doesn't mean it's safe to use an arbitarily large initial cwnd.
> It's also not quite clear how to revoke this challenge, and how domain expiration deal with this
CAs can cache the record lookup for no longer than 10 days. After 10 days, they have to check it again. If the record is gone, which would be expected if the domain has expired or been transferred, then the authorization is no longer valid.
(I would have preferred a much shorter limit, like 8 hours, but 10 days is a lot better than the current 398 day limit for the original ACME DNS validation method.)
It doesn't comply with one or more root store policies (which all incorporate the Baseline Requirements by reference, which incorporate various specs, such as RFC5280, by reference).
There are countless examples of non-compliant certificates documented in the Bugzilla component I linked above. A recent example: a certificate which was backdated by more than 48 hours, in violation of section 7.1.2.7 of the Baseline Requirements: https://bugzilla.mozilla.org/show_bug.cgi?id=2016672
Baseline requirements are not an imaginary problem. All of them have a legitimate reason for existing. You could argue that some "are not that big of a deal", but that's exactly the point, the overbearing and overly specific requirements serve both their own purpose and double as Van Halen's "no brown M&Ms" clause: if the CA screws them up, either by malice or incompetence and doesn't immediately catch them and self-report, then you know they have no way of telling what other things they are screwing up. And if you're in the business of selling trust, that instantly makes you untrustworthy.
There are countless Bugzilla reports of clearly unprofessional CAs trying to get away with doing whatever they want, get caught, say "it's no big deal", fail to learn the lesson and eventually get kicked out, much to the chagrin and bewilderment of their management, irate that some nerds on the Internet could ruin their business, failing to understand that following the scripture of the Internet nerds is the #1 requirement of the business they chose to run.
Yes. Brown M&M tests are exactly what's called for here. You want a strong psychological urge to obey rules just because they're rules. There are roles where this isn't the right thing, but operating a Certificate Authority isn't one of them.
In my experience every case in the Web PKI where we found what seems obviously to be either gross incompetence or outright criminality there were also widespread technical failures at the same CA. Principles who aren't obeying the most important rules also invariably don't care about merely technical violations, which are easier to identify.
For example, CrossCert had numerous technical problems to go along with the fact that obviously nobody involved was obeying important rules. I remember at one point asking, so, this paperwork says you issue only for (South) Korea, but, these certs are explicitly not for Korea, so, what technical measure was in place to ensure you didn't issue them and why did it fail? And obviously the answer is they didn't give a shit, they'd probably never read that paperwork after submitting it, they were just assuming it doesn't matter...
Google Chrome (along with Mozilla, and eventually the other root stores) distrusted Symantec, despite being the largest CA at the time and frequently called "too big to fail".
Given how ubiquitous LE is, I think people will switch browsers first. non-chrome browsers based on chrome are plenty as well, they can choose to trust LE despite Chrome's choices. Plus, they had a good reason with Symantec, a good reason to distrust them that is. This is just them flexing, there is no real reason to distrust LE, non-web-pki does not reduce security.
GP gave a very good reason that non-web-PKI reduces security, you just refused to accept it. Anybody who has read any CA forum threads over the past two years is familiar with how big of a policy hole mixed-use-certificates are when dealing with revocation timelines and misissuance.
"it's complicated" is not the same as "it's insecure". Google feels like removing this complexity improves security for web-pki. Improving security is not the same as saying something is insecure. Raising security for web-pki is not the same as caliming non-web-pki usage is insecure or is degrading security expectations of web-pki users. It's just google railroading things because they can. You can improve security by also letting Google decide and control everything, they have the capability and manpower. But we don't want that either.
Neither, I meant if enough people panic and stop using chrome, website operators need not worry much. Safari is default on macs, and Edge is default on windows, both can render any website that can't be accessed in Chrome, so it'll make Chrome the browser that can't open half of the websites, instead of half of the websites out there suddenly being incompatible with chrome. The power of numbers is on LE's side.
I would think it's more secure than clientAuth certs because if an attacker gets a misissued cert they'd have to actually execute a MitM attack to use it. In contrast, with a misissued clientAuth cert they can just connect to the server and present it.
Another fun fact: the Mozilla root store, which I'd guess the vast majority of XMPP servers are using as their trust store, has ZERO rules governing clientAuth issuance[1]. CAs are allowed to issue clientAuth-only certificates under a technically-constrained non-TLS sub CA to anyone they want without any validation (as long as the check clears ;-). It has never been secure to accept the clientAuth EKU when using the Mozilla root store.
> Is there a reason why dialback isn't the answer?
There are some advantages to using TLS for authentication as well as encryption, which is already a standard across the internet.
For example, unlike an XMPP server, CAs typically perform checks from multiple vantage points ( https://letsencrypt.org/2020/02/19/multi-perspective-validat... ). There is also a lot of tooling around TLS, ACME, CT logs, and such, which we stand to gain from.
In comparison, dialback is a 20-year-old homegrown auth mechanism, which is more vulnerable to MITM.
Nevertheless, there are some experiments to combine dialback with TLS. For example, checking that you get the same cert (or at least public key) when connecting back. But this is not really standardized, and can pose problems for multi-server deployments.
> It has never been secure to accept the clientAuth EKU when using the Mozilla root store.
Good job we haven't been doing this for a very long time by now :)
Sorry, it's late here and I guess I didn't word it well. Dialback (these days) always runs over a TLS-encrypted connection, as all servers enforce TLS.
The next question is how to authenticate the peer, and that can be done a few ways, usually either via the certificate PKI, via dialback, or something else (e.g. DNSSEC/DANE).
My comment about "combining dialback with TLS" was to say that we can use information from the TLS channel to help make the dialback authentication more secure (by adding extra constraints to the basic "present this magic string" that raw dialback authentication is based on).
How would dialback-over-TLS be "more vulnerable to MITM" though? I think that claim was what led to the confusion, I don't see how TLS-with-client-EKU is more secure then TLS-with-dialback
Firstly, nobody is actually calling for authentication using client certificates. We use "normal" server certificates and validate the usual way, the only difference is that such a certificate may be presented on the "client" side of a connection when the connection is between two servers.
The statement that dialback is generally more susceptible to MITM is based on the premise that it is easier to MITM a single victim XMPP server (e.g. hijack its DNS queries or install an intercepting proxy somewhere on the path between the two servers) than it is to do the same attack to Let's Encrypt, which has various additional protections such as performing verification from multiple vantage points, always using DNSSEC, etc.
If an attacker gets a misissued cert not through BGP or DNS hijacks, but by exploiting a domain validation flaw in a CA (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=2011713) then it's trivial for them to use it as a client certificate, even if you're requiring the serverAuth EKU. On the other hand, dialback over TLS would require the attacker to also MitM the connection between XMPP servers, which is a higher bar.
The good news is that since Prosody requires the serverAuth EKU, the misissued cert would be in-scope of Mozilla's root program, so if it's discovered, Mozilla would require an incident report and potentially distrust the CA. But that's reactive, not proactive.
You're not wrong. PKI has better protections against MITM, dialback has better protections against certificate leaks/misissuance.
I think the ideal approach would be combining both (as mentioned, there have been some experiments with that), except when e.g. DANE can be used ( https://prosody.im/doc/modules/mod_s2s_auth_dane_in ). But if DANE can be used, the whole CA thing is irrelevant anyway :)
Firstly, nobody is actually calling for authentication using client certificates. We use "normal" server certificates and validate the usual way
I'm not sure I understand this point. You authenticate the data you receive using the client's certificate. How is that "nobody is calling for authentication using client certificates"? Maybe there's some nuance I'm missing here but if you're authenticating the data you're receiving based on the client's certificate, then how is that "validating the usual way"?
There is a lot of confusion caused by overlapping terminology in this issue.
By "client certificates" I mean (and generally take most others in this thread to mean) certificates which have been issues with the clientAuth key purpose defined in RFC 5280. This is the key purpose that Let's Encrypt will no longer be including in their certificates, and what this whole change is about.
However when one server connects to another server, all of TCP, TLS and the application code see the initiating party as a "client", which is distinct from say, an "XMPP client" which is an end-user application running on e.g. some laptop or phone.
The comment I was responding to clearly specified " I don't see how TLS-with-client-EKU [...]" which was more specific, however I used the more vague term "client certificates" to refer to the same thing in my response for brevity (thinking it would be clear from the context). Hope that clarifies things!
> CAs are allowed to issue clientAuth-only certificates under a technically-constrained non-TLS sub CA to anyone they want without any validation (as long as the check clears ;-). It has never been secure to accept the clientAuth EKU when using the Mozilla root store.
It has never been secure to to rely on the Mozilla root store at all, or any root store for that matter, as they all contain certificate authorities which are in actively hostile countries or can otherwise be coerced by hostile actors. The entire security of the web PKI relies on the hope that if some certificate authority does something bad it'll become known.
> The entire security of the web PKI relies on the hope that if some certificate authority does something bad it'll become known.
Correct, but it's not a vain hope. There are mechanisms like certificate transparency that are explicitly designed to make sure any misbehavior does become known.
XMPP identifiers have domain names, so the XMPP server can check that the DNS SAN matches the domain name of the identifiers in incoming XMPP messages.
I've seen non-XMPP systems where you configure the DNS name to require in the client certificate.
It's possible to do this securely, but I agree entirely with your other comment that using a public PKI with client certs is a recipe for disaster because it's so easy and common to screw up.
After the WebPKI banned the issuance of new SHA-1 certificates due to the risk of collisions, several major payment processors (Worldpay[1], First Data[2], TSYS[3]) demanded to get more SHA-1 certificates because their customers had credit card terminals that did not support SHA-2 certificates.
They launched a gross pressure campaign, trotting out "small businesses" and charity events that would lose money unless SHA-1 certificates were allowed. Of course, these payment processors did billions in revenue per year and had years to ship out new credit card terminals. And small organizations could have and would have just gotten a $10 Square reader at the nearest UPS store if their credit card terminals stopped working, which is what the legacy payment processors were truly scared of.
The pressure was so strong that the browser vendors ended up allowing Symantec to intentionally violate the Baseline Requirements and issue SHA-1 certificates to these payment processors. Ever since, there has been a very strong desire to get use cases like this out of the WebPKI and onto private PKI where they belong.
A clientAuth EKU is the strongest indicator possible that a certificate is not intended for use by browsers, so allowing them is entirely downside for browser users. I feel bad for the clientAuth use cases where a public PKI is useful and which aren't causing any trouble (such as XMPP) but this is ultimately a very tiny use case, and a world where browsers prioritize the security of ordinary Web users is much better than the bad old days when the business interests of CAs and their large enterprise customers dominated.
But this has nothing to do with clientAuth as in this case the payment processor uses a server certificate and terminal connect to the payment processor, not the other way around. So this change would not have prevented this and I don't see what browsers can do to prevent it - after all, the exact same situation would have happened if the payment processors used a HTTPS-based protocol.
Yeah, the more I think about it the more futile this effort starts to look. The industry is investing tons of resources into building and maintaining an open, highly secure PKI ecosystem which allows any server on the public internet to cryptographically prove its identity, and Google wants to try to prevent anyone who's not a web browser from relying on that ecosystem? Seems impossible. The incentives are far too strong.
Google is hoping that after this change other TLS clients will go off and build their own PKI entirely separate from the web PKI, but in reality that would take way too much redundant effort when the web PKI already does 99% of what they want. What will actually happen is clients that want to use web certs for client authentication will just start ignoring the value of the extendedKeyUsage extension. The OP says Prosody already does. I don't see how that's an improvement to the status quo.
They denied my request for a service account quota increase even though my use case[1] was literally straight from their documentation. They only increased it after I complained on Twitter and got retweeted by Corey Quinn.
Why didn’t you just have the customer create a service account and then send you the key? Or you’d just have one master service account and the customer would give you permission to impersonate the one they created? I’m sorry you ran into this but there were other solutions.
Having the customer send me the key is less secure because that key never gets rotated. Google wants to discourage long-lived credentials so badly that new organizations can't even create service account keys by default anymore.
Having the customer grant permission to a single master service account is vulnerable to confused deputy attacks.
In any case, why should I have to pursue "other solutions" to something that's in their documentation?
Logs are sharded by the expiration date of the certificate, not the issuance date, so you should expect to see growth in shards covering the next 398 days (the maximum lifetime of certificates).
As for the 2025h2 logs, these will not be acquiring any newly-issued certificates, but someone might be copying previously-issued certificates from other logs.
In fact, I've read several such rants about Firefox removing functionality from other parts of their UI.
It's sure hard to make everyone happy.
reply