Bug 342567

Created attachment 90267 [details]
Patch to allow imap/smtp/managesieve to use TLSv1.2

With the following patch I managed to get TLSv1.2 working with imap/ssl, imap/starttls, smtp/ssl, smtp/starttls and managesieve connections.

The patch basically replaces the forced TLSv1.0 with QSsl::SecureProtocols.  Since TLSv1.0 is also part of QSsl::SecureProtocols (at least for now), it should not cause any regression.

Why it's necessary to patch  "kio/kio/tcpslavebase.cpp" ?

"kio/kio/tcpslavebase.cpp" change was needed to get smtp/starttls working.

I had to hunt that down once I noticed that patches to kdepimlibs were not enough.

I can't change, and don't know kio code.
I add cc "Dawit Alemayehu <adawit@kde.org>" which knows better it.

Hi Dawit could you evaluate patch (kio part please) ?

Thanks

I don't know any of this code either.  I just made a minimal patch to make it work, I don't know if it should be done like that.

I dunno this particular code base but what that patch does is bascially change the protocol to be used during SSL handshake from only TLSv1 to SSLv3/TLSv1. I am not entirely certain that QSslSocket in Qt 4.x would make a TLSv1.2 connection if you set QSsl::SecureProtocols as the protocol to be used during handshake. However, it will most definitely attempt use SSLv3 if that is the only thing available. I dunno if that is desired when making imap/smpt connections.

I verified with server log files every combination that TLSv1.2 is used with QSsl::SecureProtocols.

It is a bit unfortunate that Qt4 QSsl::TlsV1 implies that it is the latest protocol, and from the code it seems that the idea is to use latest protocols.  That was true ten years ago, but nowadays it has opposite effect to pinning the protocol to least acceptable one which has already shown weaknesses. 

I agree that SSLv3 is not ideal, but does disabling that really belong to KDE?   I would think that it should be done on lower levels or server side.    

Since imap/ssl talks already TLSv1.2 because it speaks any protocol, we could change just smtp/ssl to get TLSv1.2 functionality, and leave starttls variants to as they are.

I did have more thorough look into various versions of Qt and how things are implemented there.  

By the time of Qt 4.7 (2010), QSsl had three protocol options, SslV2, SslV3 and TlsV1, and auto negotiate AnyProtocol.  At the time openssl did not support TLSv1.1 or TLSv1.2, so the situation was relatively clear.  The auto negotiation is done by openssl.

By the time of Qt 4.8 (2011), openssl had added support for newer TLS protocols, so QSsl was expanded with two new auto negotiate options, TlsV1SslV3 and SecureProtocols.  They both behaved the some, negotiate the highest protocol excluding SslV2.  Thus, TLSv1.1 and TLSv1.2 started working with these options, as well as with AnyProtocol. 

Qt5 then added explicit versions TlsV1_0, TlsV1_1 and TlsV1_2 and made TlsV1 alias for TlsV1_0.   Then came POODLE attack and Qt 5.4 dropped SslV3 from SecureProtocols.

Now, looking KDE, it seems that it uses Qt 4.7 way of doing things and thus uses TlsV1 in many places.  More appropriate thing would be to use SecureProtocols and leave disabling SSLv3 to the Qt side, like in Qt 5.4.  That way, when for example TLSv1.3 lands, just by upgrading openssl would make it work.

KTcpSocket has at some point added new enumerations TlsV1SslV3 and SecureProtocols, but it is a bit unclear to me what it is trying to do, since in QSsl these are enumerated values and KTcpSocket redefines them somehow as bitmasks.  But these auto negotiate values and explicit protocol values are not really same thing on Qt level.

I might add that disabling SSLv3 from auto negotiation has really nothing to do with it being the only protocol available.  The problem is that man-in-the-middle can cause the auto negotiation to fail.  Even if both server and client support TLSv1.2, man-in-the-middle can signal client that protocol is not supported, thus client tries lower protocol versions until the connection with SSLv3 succeeds and is vulnerable to POODLE attack.

Any update on this?  I found this issue last night on Debian.  I, too, am trying to make my communications more secure.  TLSv1.0 is already starting to show its age and I'm sure there will be more to come.

Dawit, Teemu,

Any advice on what to do with the patch attached to this bug?
I'd like to clear this one up.  Unfortuntately us remaining kdepim devs really aren't sure how to handle it.

I am currently using Ubuntu Vivid with kubuntu-backports as it is and that works for me, and has been since Vivid was released in April.

It has been a while, but for what I remember, I saw Laurent implement some things in my patch at some point, but not all,  However, everything works for me right now without any patching of my own.

What comes to this bug, I do consider it as done.  My patch in itself, I do consider it applies to the version I reported, since I had to use it to get things working.

thanks for your fast response.
resolving then

In what version of Kmail is this fixed?

Still not working for me with 16.04.2 (KF5 5.21)

Created attachment 99540 [details]
Patch to allow imap/smtp/managesieve to use TLSv1.2 in KF5

For KF5, as packaged in kubuntu ppa backports, this allows TLSv1.2 (and later) for mail handling.   The patch contains patches for four packages and may need to be split accordingly.

 The following changes in packages were needed for KF5:

kdepim: to fix managesieve
kimap: to fix imap

kio: to fix smtp
kmailtransport: to fix smtp

Still an issue with 16.08 (KF5 5.25)

Ok, I've submitted 3 review requests to git.reviewboard.kde.org kmailtransport fix seems to be already in.

kio: https://git.reviewboard.kde.org/r/129031/
kimap: https://git.reviewboard.kde.org/r/129030/
libksieve: https://git.reviewboard.kde.org/r/129029/

kio patch is now merged too, commit 8196a735bebc6fd5eaf9d293bd565c00ef98516b

So SMTP should be working now.

All patches are not merged. Will be fixed in 16.12 with Frameworks 5.27.

With kde-frameworks 5.41 and kde-applications 17.12 KMail still uses only TLSv1.

Maybe this bug should be reopened?

Strange, I just checked, on my system (frameworks 5.40 and kde apps 17.12) I still get TLSv1.2

Strange, this might indicate some configuration error on my side.

However, I tested the same postfix server with 3 email clients: KMail, Sylpheed and K9-Mail on Android.

KMail is the only one that has these postfix logs:

    postfix/submission/smtpd[18455]: Anonymous TLS connection [...]: TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)

The other clients show this:

    postfix/submission/smtpd[18455]: Anonymous TLS connection [...]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

This is for SMTP with STARTTLS. The IMAP connections are using TLSv1.2 as expected.

Some additional info:

The problem computer (KMail only uses TLSv1 for SMTP) has ksmtp-17.12.1 which seems introduced in 17.12.

Another computer, with 17.08, has no ksmtp package and KMail successfully uses TLSv1.2 for SMTP.

I assume Andrius Štikonas was using TLS 1.2 without STARTTLS, which should work however for STARTTLS an incorrect patch was applied which hard codes TLSv1 for STARTTLS.

I have written a longer explanation here: https://github.com/KDE/ksmtp/commit/e83911f9d1963b5e7181932960f999f331b4a5f9#r29145231

Please consider to reopen this ticket

Both kimap and ksmtp suffer from the same issue. I can not connect to dovecot/postfix when I enforce protocols greater then TLSv1, because this would in turn disable STARTTLS on the connection.

This line should not be hard coded to TLSv1 in kimap:
https://github.com/KDE/kimap/blob/35464c7fd3858d70c8ac0558ecece216e3a95398/src/loginjob.cpp#L254

As a workaround I enabled smpts/imaps port (TLS without STARTTLS) to have TLSv1.2

Better file a new bug than comment on closed/fixed ones, imho

new bug report: https://bugs.kde.org/show_bug.cgi?id=394769