Repository: godot
Issue: SSL/(D)TLS certificates are not checked for revocation
Labels: bug,topic:network

### Godot version

all (as of https://github.com/godotengine/godot/commit/62047e4e4848e511a5f4e0aa84bc4f512f075f8d)

### System information

not relevant

### Issue description

Currently, Godot uses *mbedtls* for SSL/TLS support.
Also currently, certificates are not checked for revocation, so revoked (but previously valid) certificates are accepted as long as they didn't expire yet.
**If you read this as a user and want a workaround, use a short-lived certificate (like LetsEncrypt).**

There are basically two ways to check for revocation:

1. By having a giant list of revoked certificates, and checking that. These are called certificate revocation lists and are supported by *mbedtls*: it can [parse provided lists](https://tls.mbed.org/api/x509__crl_8h.html). These lists are comparatively huge (multiple MBs or even tens of MBs). They also need to be updated fairly often, so bundling with Godot releases seems not feasable; they'd need their own mechanism for updating. Mozilla switched to an improved approach called [CRLite](https://github.com/mozilla/crlite), which uses bloom filters and magic based on [this paper](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjd6sPHhanyAhVJhf0HHdVEBhMQFnoECAYQAQ&url=https%3A%2F%2Fobj.umiacs.umd.edu%2Fpapers_for_stories%2Fcrlite_oakland17.pdf&usg=AOvVaw1_YMDOlDQoX7teYu7Cm4eH) (PDF) to improve performance and size. There is a Python example client for CRLite [here](https://github.com/jcjones/crlite_status), but I couldn't get it to work on Windows as it uses path names that don't work there. But from what I've seen, even then, the revocation data is still multiple MBs and of course still needs to be updated often.
2. Live checking of certificate validity/revocation, by querying the CA's server for each checked certificate.  This approach is called OCSP. This adds quite some latency to the first request to a new unchecked domain/cert. *mbedtls* doesn't support it at all; it was mentioned as a planned feature for the 2.x series in 2015, some work was done in 2017, but it was seemingly scrapped/postponed and now isn't on the roadmap. See this issue of theirs: https://github.com/ARMmbed/mbedtls/issues/880 - so we'd need to implement this ourselves, akin to [this](https://github.com/MetLife/OCSPChecker) Python code, although it'd be probably a lot more work with our C++ codebase and without those crypto libraries.

[These Mozilla docs](https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox) about certificate revocation also offer a nice overview.

Seeing all this, I think the best way forward would be to both:
1. To wait until either *mbedtls* supports OCSP, or a better way for us to implement this is figured out.
2. ~~Document **clearly** that Godot's TLS doesn't check revocations. We also should recommend short lived certificates that are automatically managed (i.e. LetsEncrypt), as that is both a good practice and dramatically reduces the impact in case someone gets the hold of a cert's private key.~~ (Done with https://github.com/godotengine/godot/pull/51513)

Note that for a game engine like Godot, the attack surface this missing check is creating is smaller compared to a web browser. This requires a malicious actor to somehow obtain the private key for the certificate *and* to either take over the domain or use a man-in-the-middle setup to serve their version of a game's domain to a user, to then e.g. gather their login credentials used for the game or to serve them malicious scripts/DLC/PCK files or similar.

Of course, it *would* be better to check revocations. Or for everyone to abandon that approach and move to short-lived certs :)

### Steps to reproduce

- Observe that a HTTPRequest to `https://expired.badssl.com/` succeeds. Godot doesn't have any code to check for revocations.

### Minimal reproduction project

_No response_