Bug 394770

Summary: STARTTLS is restricted to TLS 1.0
Product: [Frameworks and Libraries] ksmtp Reporter: Jörg Thalheim <joerg.kde>
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: ao, arthur, dvratil, juri, teemu
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In: 5.8.2
Sentry Crash Report:
Attachments: Workaround: TLS v1 -> TLS v1.2

Description Jörg Thalheim 2018-05-27 21:43:18 UTC
KSmtp makes the assumption that TLSv1 is equal to STARTTLS

https://github.com/KDE/ksmtp/commit/e83911f9d1963b5e7181932960f999f331b4a5f9#commitcomment-29146023

This is incorrect as STARTTLS is independent from the protocol version used for cryptography.
In turn it is not possible to use newer TLS version such as v1.1 or v1.2.
Also it is not possible to use TLS 1.0 on ports without STARTTLS.

A workaround at the moment is to enable smtps (smtp without STARTTLS) on a different port to allow modern TLS version.

When fixing this issue, please also consider renaming SSL to SSL/TLS
and the current TLS option to STARTTLS in the encryption selection of Kmail.
This creates less confusion and follows other email clients such as Thunderbird.

This bug is related to the same limitation in KImap tracked in: https://bugs.kde.org/show_bug.cgi?id=394769
Comment 1 Juri Vitali 2018-05-28 23:30:44 UTC
Confirmed here too (latest Archlinux version, 18.04.1).
I would guess this is a leftover from KDE4, as the relevant version of the library involved does not mention any protocol higher than TLS v1.0 [1], while the newer Frameworks library does (and TLSV1_0 becomes an alias of TLSV1) [2].

Fow now, a quick and dirty substitution of all instances of TlsV1 to TlsV1_2 works correctly (see patch), but obviously would break any situation where the server does not support that version.

[1]: https://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKTcpSocket.html
[2]: https://api.kde.org/frameworks/kio/html/ktcpsocket_8h_source.html
Comment 2 Juri Vitali 2018-05-28 23:33:10 UTC
Created attachment 112935 [details]
Workaround: TLS v1 -> TLS v1.2
Comment 3 Juri Vitali 2018-05-29 00:06:09 UTC
Poking around the code a bit more, I think a sane default would be to use KTcpSocket::SecureProtocols, which is equal to QSsl::SecureProtocols, which in turn is defined to be by the official docs "The default option, using protocols known to be secure; currently behaves similar to TlsV1Ssl3 except denying SSLv3 connections that does not upgrade to TLS." [1].

Other than that, a switch could be given to the user to use a specific - more secure - protocol, but beyond that an update to KIO would be required, as KTcpSocket seems to be supporting only a limited subset of the Qt's TLS protocols. [2]

[1]: https://doc.qt.io/qt-5/qssl.html#SslProtocol-enum
[2]: https://api.kde.org/frameworks/kio/html/ktcpsocket_8h_source.html
Comment 4 Jörg Thalheim 2018-05-29 05:11:49 UTC
The encryption mode enum should only contain three states:

enum EncryptionMode {
        Unencrypted,
        SslOrTls,
        Starttls
};

The pseudo code should be as follow in LoginJob::doStart

if (d->m_encryptionMode == SslOrTls) {
  d->sessionInternal()->startSsl(KTcpSocket::SecureProtocols);
} else if (d->m_encryptionMode == Starttls) {
  sendCommand("STARTTLS");
} else {
  if (!d->authenticate()) {
    emitResult();
  }
}

in LoginJob::handleResponse

if (r.isCode(220)) {
   d->sessionInternal()->startSsl(KTcpSocket::SecureProtocols);
   return;
}
Comment 5 Daniel Vrátil 2018-06-03 17:00:34 UTC
Git commit 98b575dceadaed6faeb7fa302b75f1d08959126f by Daniel Vrátil.
Committed on 03/06/2018 at 16:57.
Pushed by dvratil into branch 'Applications/18.04'.

Fix TLS vs STARTTLS handling

Allow only choosing between no encryption, SSL/TLS or STARTTLS and let
KTcpSocket negotiate the best encryption protocol with the server.

FIXED-IN: 5.8.2

M  +17   -48   src/loginjob.cpp
M  +7    -5    src/loginjob.h
M  +1    -4    src/session.cpp
M  +13   -12   tests/logintest.cpp

https://commits.kde.org/ksmtp/98b575dceadaed6faeb7fa302b75f1d08959126f
Comment 6 zless 2018-06-04 10:15:36 UTC
Hello.

I just applied this patch ksmtp-17.12.3. I'm not sure if this version is supported but the patch applies cleanly. 

However there is no change. The account will still use tlsv1 only.

Do you think there is anything else I should test?
Comment 7 Jörg Thalheim 2018-06-04 10:18:56 UTC
I suppose kmail needs to be fixed as well.
Comment 8 zless 2018-06-04 11:17:31 UTC
Good point. KMail used to work fine before ksmtp was introduced (in the kde-apps 16.x days) so I just assumed this fix would be enough.
Comment 9 Daniel Vrátil 2018-06-30 14:53:20 UTC
You also need to apply this patch to kmailtransport: https://cgit.kde.org/kmailtransport.git/commit/?id=b133158dfab96d0fc2ef33ca9ef865e99bd93cfd
Comment 10 Daniel Vrátil 2018-06-30 14:53:34 UTC
*** Bug 389403 has been marked as a duplicate of this bug. ***