Kontact is vulnerable by NO STARTTLS

[Volker Krause]

On Friday, 24 September 2021 22:47:03 CEST Volker Krause wrote:
> On Friday, 24 September 2021 19:38:49 CEST Daniel Vrátil wrote:
> > On Friday, 24 September 2021 19:37:11 CEST Daniel Vrátil wrote:
> > > On Friday, 24 September 2021 18:05:43 CEST Volker Krause wrote:
> > > > On Friday, 10 September 2021 21:28:26 CEST Sandro Knauß wrote:
> > > > > #423424 - Kmail "forces" the user to accept invalid TLS certificates
> > > > 
> > > > Does anyone happen to have or know of a publicly accessible SMTP
> > > > and/or
> > > > IMAP server with self-signed or otherwise invalid SSL certificates to
> > > > test this? No account needed, this should be visible prior to logging
> > > > in
> > > > already. This would help a lot with fixing this, and would avoid me
> > > > having to break my own mail server ;)
> > > 
> > > You can try mine, the certificate is expired for 4 years (if that's the
> > > right kind of "invalid"), I did not yet get to switch to Let's Encrypt
> > > there yet :-) The domain is dvratil.cz, ports are standard.
> > 
> > Hmm, looks like just the IMAP certificate is wrong, SMTP cert is valid. So
> > if IMAP is enough, you can try that.
> 
> Actually both "work" and reproduce the problem here :)
> 
> SMTP even showed me a nice way to trigger this on my own server without
> breaking the production setup (valid certificate, but using a sub-domain not
> covered by the certificate).

There seem to be two parts to this:

(1) when the user decides to not ignore certificate errors, both KIMAP and 
KSTMP just reconnect rather than report that as an error:
https://invent.kde.org/pim/kimap/-/blob/master/src/sessionthread.cpp#L308
https://invent.kde.org/pim/ksmtp/-/blob/master/src/sessionthread.cpp#L248

No idea why this is done that way, this is fairly straightforward to change 
though.

(2) the IMAP resource doesn't seem to handle *any* connection errors and just 
reconnects whenever its session disconnects. So even without (1) it loops in 
the certificate error dialog.

I suspect this is being done to handle all kinds of transient network 
disruptions without ending up permanently switching the resource to offline.

One way to address this would be to add an additional error signal for the 
certificate error case, handle that in the resource and switch it to offline 
then. That might be a problem in case of a capture portal being responsible 
for the certificate error (ie. the certificate error being transient), but 
it's still better than being spammed by an infinite loop of error dialogs.

I haven't tested yet to what extend SMTP is also affected by (2), a similar 
approach should work if necessary, but instead of switching the resource 
offline we'd report a delivery error on the respective message.

Thoughts?

Thanks,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20210927/bcb2392a/attachment.sig>