Any idea if signing up for Google's Advanced Protection program would mitigate/prevent potential attacks from this security issue?

My understanding is that signing up for this program blocks the usual methods of installing sideloaded apps (you can't install an app's apk file from your phone's local storage), and instead requires you to physically connect your Android phone to an external computer and use the adb CLI tool to sideload apps that are not on the Google Play store.

https://landing.google.com/advancedprotection/

If you're speaking from the perspective of an enterprise making recommendations, yes that'd be an option. As a user, though, you could just avoid sideloading.

Just trying to think if there are any other potential immediate recommendations for non-technical friends and family with Android phones from these vendors other than "don't sideload any apps" and "make sure to install any security updates as soon as they're available".

A possible way this occurred was through a hacker compromising a bunch of OEMs like Samsung and LG.

If that's your threat model, "don't sideload" seems insufficient as a response. A hacker who's able to steal the private keys of Samsung and LG (the "crown jewels") may also be able to replace the official apps they upload to the Play store with apps that contain malware.

Plus if I understand other comments correctly, a stolen key allows the thief to privilege escalate from "ability to issue an update for a fart app on your phone" to "ability to root your device".

So if you're serious about security, I would uninstall apps very aggressively, especially apps from the affected OEMs. You can fool around with fart apps on a separate device if you want.

That's not how the TLS handshake works. The TLS server must be configured to request a certificate from the client in order for the client to know that it needs to send a client certificate to the server, and that server-side configuration is disabled for ~99%+ of endpoints.

TLS server implementations should be aborting the TLS connection for violating the TLS Handshake state machine if a client attempts to send a client certificate when it wasn't requested.

So while this bug affects both clients and servers, 100% of clients are parsing the server's TLS cert during the TLS handshake, but less than ~1% of servers are parsing a client's certificate during a handshake.

There is very little reason to DOS a client and a lot of reasons to attack servers.

There is a huge number of public facing services that implement mutual auth and all those are potentially vulnerable to DOS. While clients can just decide to not connect to a web service that causes their browser to malfunction (and why have you connected there in the first place?), services are usually not at liberty to ignore a client at this stage.

So yes, those servers that do request client certificate are targets and my point still stands that servers are much more affected than the clients.

What would be an affected client? You keep connecting to this infected website that causes your browser to die? Somebody embedded some tracking on their page that now points to an infected website? Everybody will just move on and it is hard to say you are very much affected by this problem.

Whereas if you are a service and you are affected you absolutely need to implement a fix.

correction: literally 99.99999% of endpoints. they use password^W SMS authentication instead. no seriously, how is the only one good thing about X.509 (authentication via public key) the only unused part (to be fair, if anyone used it, wed have a whole new 10 episodes of vuln disclosures).

> correction: literally 99.99999% of endpoints.

You made up a number with no grounding in reality because of your bias due to being "general public".

For corporate services it is actually quite common to use client certificates and mutual auth. Also popular with VPNs.

You might not be aware of this because corporations do not want to deal with people who do not know or can be forced to know how to generate signing request.

This is different when you control both the service and the users of the service and you have something valuable to protect.

As an example, I worked with credit card terminals and these used mutual auth with properly managed client certificates.

You wouldn't call DOS on all terminals and ATMS "insignificant".

No, I was purely focused on public web. As for your corporate services, those are all insecure as hell despite whaever tech they use. Anything that's remotely hidden from public in any way historically was uncovered to have non stop, gaping, and obvious security holes, even after being corrected 1-5 times. This is a result of the way businesses are run as miniature reactionary states ("just ban people in the firewall brother. call the police").

It's theoretically possible for someone to record encrypted traffic today, keep a copy of it for a decade or two until quantum computers are available, and then decrypt it in the future using the quantum computer. If you have data today, that needs to be secure for more than a few decades, you may want to move to post quantum crypto soon to stop that potential leak.