Kontact is vulnerable by NO STARTTLS

[Ingo Klöcker]

On Montag, 27. September 2021 19:00:42 CEST Volker Krause wrote:
> 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.

The code in ksmtp was copied from the code in kimap. The code in kimap is 
there since TLS support was added to kimap's LoginJob [1]. The commit log says 
"The error case needs to be handled in a better way though."
This reconnect may be a left-over from this initial implementation which 
simply reconnected without TLS if the TLS connection failed. Obviously, that's 
a no-go nowadays. I agree that reporting an error is the right thing to do.

[1] https://invent.kde.org/pim/kimap/-/commit/
797e31c893ccbdedb47f9831e4294c99cd3428d0

> (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.

A more complex solution would cache the error and the user's response. This 
would allow us to do a limited number of reconnect attempts without asking the 
user the same question multiple times. If the secure connection still fails 
after this limited number of reconnects the resource would switch to offline.

But switching it offline immediately is probably also okay if the user can 
easily switch it online again.

Regards,
Ingo
-------------- 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/e8ebf38e/attachment.sig>