The world is moving to ECDHE which makes this less trivial.

In a Diffie Hellman setup, configure the machine you aren't sat in front of (usually the server) to use a fixed secret value instead of a random one.

Now since you know this value, and the other value you need (from the client in this case) is sent over the wire, you can run the DH algorithm and decrypt everything.

You should (obviously) never do this in production, although it is what various financial institutions plan to do and they have standardised at ETSI as an "improvement" on TLS (you know, like how TSA locks are an "improvement" over actually locking your luggage so random airport staff can't steal stuff) ...

TSA locks are an improvement over having your lock broken off, not vs it remaining locked.

Using a fixed ephemeral on the other hand is going to happen in prod too...

Are they disabling suites that don't use DH exchanges on the clients? Maybe I'm behind, but I can't imagine that happening on any major client.

So inconvenient.

Security engineers around the world have been working for decades to clean up the mess made by engineers, product designers, and business owners overlooking security because it's inconvenient.

If you are a developer or engineer then eat the complexity tax as part of your responsibility and ensure that you are shipping code and products that are secure for the end user who probably doesn't have the expertise to overcome the security gaps left by "developer inconvenience".

Or, you know, abstract the application layer and then apply the TLS layer on top of it so that it can be secured, but not effect the application code/logic.

To be fair, that's been tried a lot, and it keeps causing issues.

I'm at the point where I believe that you can't "layer on" or "abstract away" security like you can with other things, it needs to be thought about at every step.

Just look at attacks that can take advantage of content-length to pluck out which page the user is requesting of a mostly-static site, or how compression and encryption seem to almost be at odds with one another.

You can't ever just assume TLS will handle it when it's abstracted away, and while HTTP/3 may not get rid of those kinds of attacks entirely, bringing "security" closer to the application logic may enable better protections.

Possibly... I'm just concerned about yet another layer to have to be far more concerned about than I already am. I really enjoy building applications. I'm pretty good at systems and orchestration to an extent, but would rather not have to focus too much.

Going from using an application framework that's more abstracted, such as ASP.Net (not mvc/api/core) to those where you are closer to the metal (node, python, .net core/mvc/api) was a jump.

Thinking in terms of leveraging push with HTTP/2 alone has me concerned. The tooling around building web applications hasn't even caught up to the current state of being, let alone moving farther. Another issue is dealing with certificates against local/internal development in smaller organizations. It may get interesting, and it may get more interesting than it's actually worth in some regards.