4 ms·
TLS libraries by default don't have this behavior. It's been years since I read the TLS spec, but a host wildcard like this isn't normally possible, since it b
by mannyv 3y ago
TLS libraries by default don't have this behavior.
It's been years since I read the TLS spec, but a host wildcard like this isn't normally possible, since it bypasses host verification completely.
And the CA verification bypass is also out of line with normal behavior. CA verification is another TLS bedrock behavior.
Together, these basically disable TLS verification. I'm surprised they didn't disable date checking too, because why not go for it at this point.
This isn't a bug, this is designed.
- mynameisvlad 3y agoOr it’s two separate bugs that were introduced at wildly different times (which the article mentions; the first bug was there pre-5.5.5 but useless on its own). It’s quite a stretch to say that an engineer designed a multi-year project to surreptitiously break TLS so third party stores could be used without CFW (which is also pretty trivial to do on the WiiU).
- ctz 3y ago> TLS libraries by default don't have this behavior. No, but the most popular one gives you just a callback and people end up using that to build their own insecure, weird strategies. That's how we end up with things like "the certificate is valid if the issuer DN is this hardcoded string" (very common attempt at pinning an issuer), or "the certificate chain is valid if the chain contains this precise value" (this one, likely another failed attempt at pinning), or indeed the Hashicorp Vault vuln the other week which was roughly "the certificate is valid if it has the right AKID and serial number".