Many enterprises use a FIPS SSL proxy for all employees web traffic, so all websites with these lets encrypt will effectively be invalidated if the proxies are using openssl FIPs modules, same for FIPS client side applications
When I, as a website host, need to choose between accepting millions of Android devices or a few organizations with an esoteric security configuration, I'll go for the Android devices.
AFAIK Windows FIPS mode is unaffected by the OpenSSL bug, so not all FIPS modules will have trouble with the Let's Encrypt certificate. A Windows-based MitM-attack won't have this problem.
The best solution here would be for OpenSSL to have a FIPS release ready before September, or to release a patched version of 1.0.X, but that still won't help companies that cannot or will not update their software.
Mandatory password changes for example have not been recommended[0] by NCSC in the UK since ~2018. Continuing to do so is either legacy or misguided.
As for "MitM" it's usually due to regulatory requirements to protect and inspect at boundaries to and from an organisations network.
FIPS and OpenSSL is an interesting subject. Many organisations rely on it, yet relatively few contribute financially. When 1.1.X and subsequent versions came along and had no FIPS 140-2, orgs were forced to wait it out until someone else pays to get it accredited or pony up and help the process along. I haven't looked lately at how much has been contributed to the effort but I suspect it's still pretty low considering how much of the world relies on OpenSSL.
[0]https://www.ncsc.gov.uk/collection/passwords/updating-your-a...
High complexity / weird rules too - and not one password across systems as they have endless DIFERRENT login systems.
So your tax software itself will require 90 day resets for all staff using that, every interface to IRS requiring it (which means every login for little used systems). It's bonkers. My worry - how do they even correlate / track login risk given all these different systems. Google (which has never required a password rotation) seems to be able to really figure out when risk is higher (new device from a new location) and lower (same device from 5 minutes ago). That makes turning on 2 factor with a hardware device MUCH easier - because it doesn't annoy you unnecessarily.
Even Microsoft has stopped recommending regular password changes. I think password changes can certainly be necessary, for example when problems are found during an audit or when there are indications of abuse, but these old rules are making everyone's lives so much harder than they need to be. I hope the IRS will reconsider soon.
Google's method is quite advanced (different tiers of trust for different kinds of services). It makes total sense that you can search the web using an old session, but need to redo the whole 2FA flow if you want to change your password or recovery options. Unfortunately, working such a system out can be quite a challenge because it's hard to get the API segregated into the right trust levels without massively complicating the code flow.
Then for targeted attacks, allow non-sms two factor with multiple keys and recovery codes. I'm non SMS two factor on google with recovery codes in a drawer. Have never changed my password and actually have it memorized (and I only use it for google). Same password for 15+ years or so now. Feel totally secure. Google authenticator on phone is pretty good because people really keep track of their phone (more so than yubico keys). I have a yubico on keychain which works 90% (a bit awkward in some cases).
At this point I just assume that any password that's been leaked (hashed or not) is in plaintext in some database. Obviously 20-character random passwords aren't going to get reversed but there's no guarantee that they were always hashed and weren't leaked from the login process itself, etc.
Individuals have been migrated a few times and a few different logins.
IRS had a "get transcript" service. It had things like super secure passwords and password rotations, but password reset and setup could be done with social security + some real basic info from credit reports (ie, where did you live etc) and didn't not timeout.
So think - 100's of thousands of fake accounts for the hackers, and pain for the real users.
That's pretty common in the US for govt systems - the password reset process is often ridiculously easy because some systems have so many reset requests you can't function with anything careful.
Imagine folks in govt - 10 systems, 90 day password rollover and there was a move for a while to 12 character passwords with no reuse and upper / lower / special / numbers (but special characters are limited so password generators often error out). It got so bad there was one reset process that was outsourced to a third party AND all you had to provide was the username which was derived from the users full name. They then gave you a new password over the phone. It was honestly easier to reset then even fight the system. You have a new intern whose forgotten their password, IT just calls reset help desk for a new one.
The security problems in all this are
1) reset process so weak
2) everyone - and I mean everyone, writes these passwords down in a text file on computer
3) because new account setup can be ridiculously long - a fair bit of password sharing, so these passwords tend to end up all over the place (training documents etc etc) which then of course end up online somewhere.
I could go on.
Well they're two different things. One is an often government-mandated security standard. The other is a business requirement to be able to audit network traffic, which is also often a government-mandated requirement (due to regulations, due diligence, contractual requirements, etc).
People making tech stuff very often forget that the entire world does not work based on "technical best practices", it works on laws and contracts and customer/business requirements. In the real world there is often no perfect way to satisfy all requirements.
I don't expect the government to have different departments work together around this stuff, but knowing the technical details, the end result is still impractical and stupid. The end result of stupid rules and requirements is that the real world application of technology is stupid, as we have probably all experienced one way or another during our lives.
Just because there's a real business need for something, doesn't stop that from being silly. Correcting the silliness is clearly not a technological challenge, we'll have to wait for politicians and managers to do that, but the end result is still a confusing and contradictory mess.
You can't practically use the web like that.
is looking at a corporate firewall blocking Stack Overflow right now
... "practical" is setting your expectations a bit high.
By no means do I expect vendors of "SSL inspection" devices to act any sooner than that.