I'm sure this will be buried, but SSL is supposed to provide encryption. That's it.
Self-signed custom certs also does that. But those are demonized.
Also SSL also tries to define a ip-dns certification of ownership, kind of.
There's also a distinct difference between 'this cert expired last week' and 'this cert doesn't exist' and mitm attack. Expired? Just give a warning, not a scare screen. MITM? Sure give a big scary OHNOPE screen.
But, yeah, 47 days is going to wreck havok on network and weird devices.
If there was no IP/DNS ownership verification, how would you even know you had been MITMed? You think the attacker is going to set a flag to let you know the certificate is fake?
The only real alternative to checking who signed a certificate is checking the certificate's fingerprint hash instead. With self-signed certificates, this is the only option. However, nobody does this. When presented with an unknown certificate, people will just blindly trust it. So self-signed certificates at scale are very susceptible to MITM. And again, you're not going to know it happened.
Encryption without authentication prevents passive snooping but not active and/or targeted attacks. And the target may not be you, it may be the other side. You specifically might not be worth someone's time, but your bank and all of its other customers too, probably is.
OCSP failed. CRLs are not always being checked. Shorter expiry largely makes up for the lack of proper revocation. But expiration must consequently be treated as no less severe than revocation.
True, I get where you're coming from, but I think there's more problems even in those implied answers.
Homoglyph attacks are a thing. And I can pay $10 for a homoglyph name. No issues. I can get a webserver on a VM and point DNS. From there I can get a Letsencrypt. Use Nginx to point towards real domain. Install a mailserver and send out spoofed mails. You can also even set up SPF/DKIM/DMARC and have a complete attested chain.
And its all based on a fake DNS, using nothing more than things like a Cyrillic 'o'.
And, the self-signed issue is also what we see with SSH. And it mostly just works too.
The security situation with SSH is actually kind of dismal. You're right that standard SSH server configurations are generally equivalent to self-signed certificates but the trust model often used there is known as TOFU ("trust on first use") and is regarded by people who practice computer security as fundamentally broken. It persists only because the problem is hard to solve and it is still better than nothing and SSH gets targeted for MITM a lot less than HTTPS (SSH is targeted much more by drive-by attacks looking for weak passwords).
TLS with Web PKI is a significantly more secure system when dealing with real people, and centralized PKI systems in general are far more scalable (but not hardly perfect!) compared to decentralized trust systems, with common SSH practices near the extreme end of decentralized. Honestly, the general state of SSH security can only be described as "working" due to a lack of effort from attackers more than the hygienic practices of sysadmins.
Homoglyph attacks are a real problem for HTTPS. Unfortunately, the solutions to that class of problem have not succeeded. Extended Validation certificates ended up a debacle; SRP and PAKE schemes haven't taken off (yet?); and it's still murky whether passkeys are here to stay. And a lot of those solutions still boil down to TOFU since, essentially, they require you to have visited the site at least once before. Plus, there remain fallback options that are easier to phish against. Maybe these problems would have been more solvable if DNSSEC succeeded, but that didn't happen either.
It's hard to think of a real-world problem that PAKEs solve for HTTPS.
I see it useful as part a layered strategy: X.509 certificates establish the authenticity of the server for that domain, while the SRP/PAKE would establish the authenticity of the legal entity you're actually trying to reach. In the case of a homoglyph-assisted phisher, this would prevent them from obtaining the real password or any credential that would be useful to attack the real target, and also warn the user not to trust them period. However, the current layering of HTTPS doesn't make it possible to enforce the use of secure password exchange, and so I think passkeys are a better solution, because they allow us to remove the password modality entirely.
I'm not entirely sure about how effective passkeys would be against homoglyph-assisted MITM though. Assuming you've visited the legitimate domain before and established your passkey at that time, your passkey wouldn't be selected by the browser for the fake domain. But if you started with the fake domain, and logged in through it using a non-passkey method (including first sign up or lost-credential recovery), then I would think the attacker could just enroll his own passkey on your behalf. Now, if we layered passkeys on top of mTLS, then we could almost entirely eliminate the MITM risk!
As you note, we already have a system that uses more appropriate cryptography (than a PAKE) to solve this: FIDO.
You've lost me at mTLS here. At some point it starts to feel like we're advocating for security protocols just so we can fit them all in somewhere.
That was a bit tongue-in-cheek, sorry. I've worked in mTLS shops and it's definitely not practical for the public Internet.
Ultimately, I think the practical solution to homoglyphs is in the presentation layer, whether it be displaying different scripts in different ways, warning when scripts are mixed, or some other kind of UX rather than protocol change. The only protocol change I can think of to address them would be to go back to ASCII only (and even that is more of a presentation issue since IDNs are just Punycode).
mTLS is going to be a problem soon, arguably bigger than this lifetime reduction. Most server certs today have clientAuth EKU and can be used for mTLS. That stops next year.
It took me awhile to dig up evidence for this, but the closest I can find is that subordinate CA certificates will no longer be allowed to have id-kp-clientAuth EKU [1], however this restriction does not apply to leaf certificates.
[1]: https://googlechrome.github.io/chromerootprogram/#321-applic...