Add config option for ignoring TLS validation for certain domains/wildcarded domains #108

New issue

Open

opened 2024-01-22 04:57:44 +00:00 by girlbossceo · 0 comments

girlbossceo commented

2024-01-22 04:57:44 +00:00

(Migrated from github.com)

Conduit supports SOCK5 proxies so allowing users to exclude TLS verification from *.onion can enable both clearnet + Tor federation at the same time.

This MR isn't going anywhere, been open for 2 years, stalled on weird pedantic discussions about MITM and TLS, and the design of how it works still requires onion operators to generate a TLS certificate for themselves which is completely pointless on Tor, so it doesn't achieve anyone's goals other than some weird obscure setup where you Tor federation only with operators who generate an invalid self-signed TLS certificate (aka no one). This MR only allows trusting certificates, not ignoring certificate/TLS validation.

Basically how Synapse's federation_certificate_verification_whitelist works but with a bit more safety and verbosity when it's in use. For example, don't let the user exclude everything "*", log at least warn on startup when it's in use every time, and only allow the user to wildcard exclude known protocols like I2P and Tor.

Alternatively, I could just merge the two ideas together for the best security and usability compromise: Only allow disabling TLS verification on known protocols like I2P and Tor, and allow user to trust (but not disable) certificates from domains/subdomains but not entire TLDs for things like an internal federation setup using a private CA. User should be allowed to do either of these on known reserved local TLDs like .home.arpa, .local, and .localhost.

So with this setup:

the user can disable TLS verification on *.onion (don't attempt to validate or connect over TLS) and *.home.arpa
trust all certificates in *.local and *.corp.girlboss.ceo but still expect TLS
cannot disable TLS verification on * or *.com
cannot trust all certificates in *.net or *

Sounds quite convoluted but this is likely the best way to do it with minimal risk. No priority because this is pretty niche.

Conduit supports SOCK5 proxies so allowing users to exclude TLS verification from `*.onion` can enable both clearnet + Tor federation at the same time. [This MR](https://gitlab.com/famedly/conduit/-/merge_requests/55) isn't going anywhere, been open for 2 years, stalled on weird pedantic discussions about MITM and TLS, and the design of how it works still requires onion operators to generate a TLS certificate for themselves which is completely pointless on Tor, so it doesn't achieve anyone's goals other than some weird obscure setup where you Tor federation only with operators who generate an invalid self-signed TLS certificate (aka no one). This MR only allows *trusting* certificates, not ignoring certificate/TLS validation. <hr> Basically how Synapse's [`federation_certificate_verification_whitelist`](https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#federation_certificate_verification_whitelist) works but with a bit more safety and verbosity when it's in use. For example, don't let the user exclude everything `"*"`, log at least warn on startup when it's in use every time, and only allow the user to wildcard exclude known protocols like I2P and Tor. Alternatively, I could just merge the two ideas together for the best security and usability compromise: Only allow disabling TLS verification on known protocols like I2P and Tor, and allow user to trust (but not disable) certificates from domains/subdomains but not entire TLDs for things like an internal federation setup using a private CA. User should be allowed to do either of these on known reserved local TLDs like `.home.arpa`, `.local`, and `.localhost`. So with this setup: - the user can disable TLS verification on `*.onion` (don't attempt to validate or connect over TLS) and `*.home.arpa` - trust all certificates in `*.local` and `*.corp.girlboss.ceo` but still expect TLS - cannot disable TLS verification on `*` or `*.com` - cannot trust all certificates in `*.net` or `*` Sounds quite convoluted but this is likely the best way to do it with minimal risk. No priority because this is pretty niche.