option to ignore UnknownIssuer during TLS handshake

[sjwo]

Is there a config option to ignore the UnknownIssuer error?

E.g.:

Checking IMAP integrity… 2025-01-17T21:11:55.303608Z ERROR rustls_platform_verifier::verification::others: failed to verify TLS certificate: invalid peer certificate: UnknownIssuer

This is a case where the mail server's TLS certificate is not signed by one of the usual CA's whose certificates are installed by default (e.g. on Ubuntu), and where I understand the risks involved in ignoring the error.

If there is not such an option, then I'd like to propose one as a new feature.

Thanks! Excited to try Himalaya once I get over this hurdle.

[soywod]

It is not really an error as it does not stop the app, but rather an informative log. Logs follow the env_logger convention, which means that you can filter logs from the RUST_LOG environment variable. In your case, you could do sth like:

RUST_LOG=warn,rustls_platform_verifier::verification::others=off himalaya

[sjwo]

it does not stop the app

It appears to stop the app:

$ himalaya
2025-01-19T16:09:38.975956Z ERROR rustls_platform_verifier::verification::others: failed to verify TLS certificate: invalid peer certificate: UnknownIssuer
Error:
   0: cannot build IMAP client
   1: cannot connect to IMAP server mailhost.cs.unh.edu:143 using STARTTLS
   2: cannot connect to TLS stream
   3: invalid peer certificate: UnknownIssuer

Note: Run with --debug to enable logs with spantrace.
Note: Run with --trace to enable verbose logs with backtrace.
$

[soywod]

Oh wait, I did not understand you have an error following the log. I thought you just wanted to get rid of the log. Which OS do you run? FYI Himalaya uses rustls with rustls-platform-verifier (the UnknownIssuer error comes from there). I quickly checked and I did not see any option, I'm afraid you will have to manually trust the certificate from mailhost.cs.unh.edu on your OS.

[sjwo]

Which OS do you run?

Ubuntu 24.04.1

I quickly checked and I did not see any option

You mean in rustls itself or in Himalaya?

[soywod]

You mean in rustls itself or in Himalaya?

In rustls. Let me know if you were able to register your certificate. I will try to have a deeper look during the week.

[sjwo]

I quickly checked and I did not see any option

You mean in rustls itself or in Himalaya?

In rustls.

Ok.

I will try to have a deeper look during the week.

Ok, thanks! I would be interested in helping to add a very simple, non-interactive, account-specific option to Himalaya (disabled by default, could be enabled by option in config file) to catch and ignore this error from rustls, if that sounds like something you'd want to have and could give me some pointers on where in the code base to start.

Let me know if you were able to register your certificate.

Not my forte and have tried a couple things that have not worked, but learning more about it.

[gl-yziquel]

I get a similar error trying to connect to the Proton Bridge v3.17.0.

invalid peer certificate: Other(OtherError(CaUsedAsEndEntity))

[soywod]

Did you try to just disable encryption? backend.encryption.type = "none"

[gl-yziquel]

backend.encryption.type = "none"

No. I've had trouble finding the documentation. The himalaya book disappeared, so I've been running in circles with certificates. And didn't know "none" was acceptable as an encryption method.

Ideally, I'd like to find a way to get self-signed certificates more easily supported with rustls applications. As of today, it's a real blain-splitter to get himalaya to query the proton bridge with SSL support set up correctly.

[soywod]

No. I've had trouble finding the documentation. The himalaya book disappeared, so I've been running in circles with certificates. And didn't know "none" was acceptable as an encryption method.

In the Configuration section of the README you have a subsection for Proton Bridge. See also the config.sample.toml.

Ideally, I'd like to find a way to get self-signed certificates more easily supported with rustls applications. As of today, it's a real blain-splitter to get himalaya to query the proton bridge with SSL support set up correctly.

I agree. As I said in #556, at this point I will have to create a Proton account and debug myself Proton Bridge. Many things are not working as expected there.

[gl-yziquel]

Did you try to just disable encryption? backend.encryption.type = "none"

2025-02-05T14:20:01.274538Z  WARN email::imap: authentication failed mechanism=Plain err=Stream(State(Flow(MalformedMessage { discarded_bytes: [43, 13, 10] })))

[soywod]

The discarded bytes are really strange, hence the MalformedMessage. @duesee is it allowed for IMAP servers to reply just +\r\n?

[duesee]

is it allowed for IMAP servers to reply just +\r\n?

https://github.com/duesee/imap-codec/blob/f00098a4ae6b0d4ee7e5ac5295b2909efa97e9e0/imap-codec/src/response.rs#L261

No, it's not. But I was surprised there is no quirk yet. I implemented a quirk for this already but maybe it got lost during some refactoring... I'll add it :-)

[duesee]

modern-email/defects#7

[gl-yziquel]

@soywod @duesee Maybe the situation is crystal clear to you, but on my end, with the proton bridge being local, setting up a half baked CA cert to resign proton bridge self signed cert, dabbling into cfssl for that, banging my head on mandatory STARTLS support and the himalaya config file that is changing month after month, well, I'm completely in the dark about the subtleties of the IMAP chunk of bytes I gave. I'm not even sure what I'm doing is half right, so...

1. Could you explain a bit what is going on and what you understand of this issue ?

2. Are you sure you are not jumping the gun on the basis of an IMAP chunk of bytes coming from someone (me) who is barely understanding at which point he is succeeding or failing at making the proton bridge make any sense when it spouts bytes ?

Just saying...

[soywod]

Maybe the situation is crystal clear to you, but on my end, with the proton bridge being local, setting up a half baked CA cert to resign proton bridge self signed cert, dabbling into cfssl for that, banging my head on mandatory STARTLS support and the himalaya config file that is changing month after month, well, I'm completely in the dark about the subtleties of the IMAP chunk of bytes I gave. I'm not even sure what I'm doing is half right, so...

If it can sooth you a bit, we also feel the same regarding IMAP. Damian banged his head more than once about writing decent libaries about IMAP, and I banged my head more than once trying to write a usable email CLI. That's why we try to change (improve) things, but it's not easy. Welcome to the email world!

1. Could you explain a bit what is going on and what you understand of this issue ?

Sure. It looks like the IMAP server part of the Proton Bridge returns malformed messages. To be more precise, Proton Bridge initiates an empty continuation request +\r\n but omits the space that should be between the + and the new line \r\n. A fix is on its way for imap-codec to be more flexible and accept those malformed messages. I will let you know whenever the fix lands on Himalaya CLI.

2. Are you sure you are not jumping the gun on the basis of an IMAP chunk of bytes coming from someone (me) who is barely understanding at which point he is succeeding or failing at making the proton bridge make any sense when it spouts bytes ?

Not sure to fully understand this point, but the log you gave in this comment is quite explicit: #546 (comment)

The discarded_bytes: [43, 13, 10] correspond to ASCII codes of +, \r then \n.

---

I understand your frustation, and I am sorry about that. Unfortunately the email world reflects perfectly your frustration. Projects are still young, but we definitely want to improve things. It will take a while.

[gl-yziquel]

I understand your frustation, and I am sorry about that. Unfortunately the email world reflects perfectly your frustration. Projects are still young, but we definitely want to improve things. It will take a while.

No worry. I perfectly understand where you are at.

[gl-yziquel]

I tried with mutt.

SSL failed: error:0A0000C6:SSL routines::packet length too long

I'm not sure if the issue is himalaya specific.

[soywod]

SSL failed: error:0A0000C6:SSL routines::packet length too long

Does not look like the same issue? Really strange.

A fix is on its way to accept empty continuation requests: duesee/imap-codec#639