https://bugs.kde.org/show_bug.cgi?id=342567
--- Comment #9 from Teemu Torma <[email protected]> --- 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. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Kdepim-bugs mailing list [email protected] https://mail.kde.org/mailman/listinfo/kdepim-bugs
