Add option to bypass certificate verification for self-signed certificates

[ecker00]

The current Client::rustls() method uses rustls-platform-verifier which enforces strict certificate verification, causing failures with self-signed certificates (e.g., ProtonMail Bridge).

Error: failed to verify TLS certificate: invalid peer certificate: Other(OtherError(CaUsedAsEndEntity))

Cause

The issue is in src/client/tokio.rs in the upgrade_rustls() method:

let mut config = ClientConfig::with_platform_verifier();

rustls-platform-verifier is designed for security and intentionally doesn't provide bypass options. To ignore certificate verification, we need to use core rustls with a custom ServerCertVerifier.

Current vs. Needed Flow

Current: imap-client → rustls-platform-verifier → OS certificate store → REJECT self-signed

Needed: imap-client → custom rustls config → DangerousNoCertificateVerifier → ACCEPT all

Proposed Solution

Add an alternative method that bypasses rustls-platform-verifier entirely:

pub async fn rustls_dangerous(host: &str, port: u16, starttls: bool) -> Result<Self, ClientError>

// Implementation replaces platform verifier with custom verifier
async fn upgrade_rustls_dangerous(mut self, starttls: bool) -> Result<Self, ClientError> {
    let config = ClientConfig::builder()
        .with_safe_defaults()
        .with_custom_certificate_verifier(Arc::new(DangerousNoCertificateVerification))
        .with_no_client_auth();

    config.alpn_protocols = vec![b"imap".to_vec()];
    // ... rest of TLS setup unchanged
}

struct DangerousNoCertificateVerification;
impl ServerCertVerifier for DangerousNoCertificateVerification {
    fn verify_server_cert(
        &self,
        _end_entity: &Certificate,
        _intermediates: &[Certificate],
        _server_name: &ServerName,
        _scts: &mut dyn Iterator<Item = &[u8]>,
        _ocsp_response: &[u8],
        _now: SystemTime,
    ) -> Result<ServerCertVerified, Error> {
        Ok(ServerCertVerified::assertion())
    }
}

Related Issues

This is needed for trusted local servers like ProtonMail Bridge that use self-signed certificates where the user explicitly accepts the security risk.

• Himalaya issue: option to ignore UnknownIssuer during TLS handshake himalaya#546
• Himalaya discussion: add options: `--no-verify-ssl` and `--trusted-ca` himalaya#568

---

Note: I'm not a Rust developer - this analysis came from working with Claude Sonnet via the CLI to figure out how to bypass verification for self-signed certificates. If I had the time I would compile and verify this, but don't have the chance right now. Hopefully it's useful and not just noise.

[soywod]

This is definitely helpful, because I did not find any option in rustls-platform-verifier to do so. It makes sense to just discard the whole crate. It should be fairly easy to implement, stay tuned!

[duesee]

@ecker00, you should take a look at https://github.com/FiloSottile/mkcert. 99% of the time, disabling certificate checks is the wrong solution. Can you give it a try?

Is the bridge running locally? Maybe you could also use plaintext then? (Not ideal, but...) rustls made it difficult to disable certificate checks for many good reasons :-)

I think we should question some use cases before adding options to circumvent security measures.

[soywod]

Interesting approach @duesee. So in your opinion an option to trust certs for testing purpose is not necessary, right? Better to ask users to create certs?

[duesee]

Admittedly, creating a local cert is more advanced than using, e.g., verify_certificate=false.

But it is definitely the more sustainable approach and mkcert makes it really easy. You learn once how to do it and can apply this skill in many situations.

Maybe my message sounded too strict... I'm not sure it will work out for everyone but figured we should at least hint to this solution and ask to give it a try. If, for some reason, it is prohibitively difficult, we could rethink.

This could serve as a quickstart: https://github.com/duesee/imap-proxy?tab=readme-ov-file#using-tls

I would be super interested if (and how) this could work out!

[soywod]

Maybe there is some Rust alternative, so we can generate certs from Himalaya itself? It would make the user experience a bit less painful.

[ecker00]

Just want to add that I think there is value in allowing a bypass, as for example with Proton Bridge it runs on localhost but it forces SSL or STARTTSL as the only options, no plain text.

[duesee]

Just want to add that I think there is value in allowing a bypass, as for example with Proton Bridge it runs on localhost but it forces SSL or STARTTSL as the only options, no plain text.

That's fine -- plaintext would be the last resort anyway. Let's forget about it. What I was trying to say: Can you try creating a custom TLS certificate with the mkcert tool I mentioned and configure Proton Bridge to use it? When you trust the CA of your local certificate you will get a secure and seamless local encrypted connection without the need to disable the certificate check. Happy to help if you run into any issues!

[duesee]

As an alternative... maybe we could allow to trust specific certificates. Something like trust_additional_certificates = [hash(public_key_of_cert)]. Or: disable_certificate_checks_if_localhost. Just an idea...

[ecker00]

Actually in the settings now I see Proton Bridge has "Export TLS certifivates" where I pick a directory then it gives me a key.pem and a cert.pem file.

In layman terms, how would I get these to work with Himalaya? Do I place these in a folder that the ~/.config/himalaya/config.toml himalaya config points to?

[soywod]

In layman terms, how would I get these to work with Himalaya?

At the moment there is no way to points to custom certs. Not sure if there is a way to "register" such custom certs to the OS, so they can be discovered automatically by rustls-platform-verifier (and more specificaly rustls-native-certs) @duesee?

[duesee]

Not sure if there is a way to "register" such custom certs to the OS, so they can be discovered automatically by rustls-platform-verifier (and more specificaly rustls-native-certs).

You can, and mkcert basically does that for you. It generates your own root certificate noone else can (mis)use, and registers it in your system trust store. You can then use the root certificate to derive as many leaf certificates as you want. In this specific case, you would create a certificate for localhost and configure the Proton bridge to use it. This way all local software would trust the bridge, not only Himalaya. (I have to say that I didn't find any documentation from Proton so far how to set a custom certificate + key.)

If we want to accept certificates we don't control, we may try to avoid putting them in our system trust store. We should pass them explicitly to the verifier. This is definitely possible for custom root certificates. But I think that self-signed certificates might work, too. See here https://docs.rs/rustls-platform-verifier/0.5.3/rustls_platform_verifier/struct.Verifier.html#method.new_with_extra_roots.

Would love to give it a try, but will take some time :-( As a first experiment I would try to use the certificate @ecker00 already exported through new_with_extra_roots -- maybe this is enough.

[soywod]

Would love to give it a try, but will take some time :-( As a first experiment I would try to use the certificate @ecker00 already exported through new_with_extra_roots -- maybe this is enough.

With great pleasure, but at least wait for the IMAP client to be refactored. Should come soon.