By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 2764 - Konqueror (or tdelibs?) does not support TLSv1.2
Summary: Konqueror (or tdelibs?) does not support TLSv1.2
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdenetwork (show other bugs)
Version: R14.0.x [Trinity]
Hardware: Other Linux
: P5 normal
Assignee: Slávek Banko
URL:
Depends on:
Blocks: R14.0.5
  Show dependency tree / graph
 
Reported: 2017-03-31 05:57 CDT by linux
Modified: 2017-04-11 11:35 CDT (History)
4 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
tdelibs : Allow all TLS versions (1.09 KB, patch)
2017-04-05 21:58 CDT, Slávek Banko 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description linux 2017-03-31 05:57:52 CDT 
Konqueror cannot connect to some HTTPS sites, such as https://wiki.kernel.org/

Wireshark shows that it sends a TLS 1.0 Client Hello and the server closes the connection with RST. Seems that TLSv1.2 is required - connecting to the same site using links (console-based browser) works, showing TLSv1.2 in Wireshark.

TDE 14.0.5 development on Debian Jessie.
Comment 1 Slávek Banko 2017-04-05 21:57:20 CDT 
Although the switch in the UI is one and is called Enable TLS..., internally corresponding variable is called "tlsv1". It may seem a bit ambiguous. To establish the connection is then used function TLSv1_client_method, however with newer versions of OpenSSL are available also functions - TLSv1_1_client_method and TLSv1_2_client_method.

Because the user has one switch for TLS, I suggest instead of TLSv1_client_method use TLS_client_method, which selects the best available method. See attached patch.

What is your opinion?
Comment 2 Slávek Banko 2017-04-05 21:58:28 CDT 
Created attachment 2764 [details]
tdelibs : Allow all TLS versions
Comment 3 linux 2017-04-06 02:02:21 CDT 
Makes sense. Does it fix the problem?
Comment 4 Slávek Banko 2017-04-06 02:24:03 CDT 
(In reply to linux from comment #3)
> Makes sense. Does it fix the problem?

Yes, the proposed patch is already successfully tested :)
Comment 5 linux 2017-04-07 05:36:29 CDT 
Great.

SNI support would be great too. Shouldn't be hard - looks like a single call to SSL_set_tlsext_host_name() before initiating the connection should do it.
Comment 6 Slávek Banko 2017-04-10 12:00:36 CDT 
Patch from attachment 2764 [details] pushed to GIT in hash adb9d9d2 (master) and f83e4b47 (r14.0.x).

In addition, also pushed patch with GIT hash 45cf7d13 (master) and f23de663 (r14.0.x) to add support for SNI in KSSL!

I am aware that proxyPeer.ascii() is not sufficient for IDN, but I think that for the full support IDN is necessary to first solve some other problems. So I believe that better imperfect SNI support, than none at all :)
Comment 7 linux 2017-04-11 06:03:44 CDT 
Thanks, both TLSv1.2 and SNI seem to work great.

But I noticed that connection to one of my SMTP servers (Exim) broke. Wireshark showed that KMail/Kontact was trying to connect using TLSv1.1 and the connection failed with TLS alert "Illegal Parameter". Found this line in server configuration:
tls_require_ciphers = NORMAL:-VERS-TLS1.2
Removed it and connection now works with TLSv1.2.

The other three servers (Postfix) happily use TLSv1.2.
Comment 8 linux 2017-04-11 09:36:00 CDT 
One mystery remains (slightly off-topic). Now with SNI, Kopete can get the correct certificate from a XMPP server (Prosody). But it does not like it:

The certificate of server xxx could not be validated for account yyy: The Certificate Authority is invalid.

However, the same certificate (fullchain.pem generated by Let's encrypt) works without any complaints through HTTPS in Konqueror.

Other XMPP account with Comodo cert works fine...
Comment 9 Slávek Banko 2017-04-11 09:46:02 CDT 
(In reply to linux from comment #8)
> One mystery remains (slightly off-topic). Now with SNI, Kopete can get the
> correct certificate from a XMPP server (Prosody). But it does not like it:
> 
> The certificate of server xxx could not be validated for account yyy: The
> Certificate Authority is invalid.
> 
> However, the same certificate (fullchain.pem generated by Let's encrypt)
> works without any complaints through HTTPS in Konqueror.
> 
> Other XMPP account with Comodo cert works fine...

It has a simple explanation: Konqueror uses KSSL (already includes SNI support), Kopete uses tqca-tls (still lacks SNI support).
Comment 10 linux 2017-04-11 11:13:17 CDT 
Thanks for explanation. I've even setup the server so my certificate is the default one (when SNI does not work) and the problem persists. Probably tqca-tls handles certificates differently.
Comment 11 Slávek Banko 2017-04-11 11:21:00 CDT 
(In reply to linux from comment #10)
> Thanks for explanation. I've even setup the server so my certificate is the
> default one (when SNI does not work) and the problem persists. Probably
> tqca-tls handles certificates differently.

My first assumption is that in the tqca-tls is not loaded list of CA. It would probably be a good idea to open a separate bug report for tqca-tls.
Comment 12 Slávek Banko 2017-04-11 11:24:09 CDT 
(In reply to linux from comment #7)
> Thanks, both TLSv1.2 and SNI seem to work great.
> 
> But I noticed that connection to one of my SMTP servers (Exim) broke.
> Wireshark showed that KMail/Kontact was trying to connect using TLSv1.1 and
> the connection failed with TLS alert "Illegal Parameter". Found this line in
> server configuration:
> tls_require_ciphers = NORMAL:-VERS-TLS1.2
> Removed it and connection now works with TLSv1.2.
> 
> The other three servers (Postfix) happily use TLSv1.2.

This is strange because TLS_client_method should ensure selection of the best suitable encryption protocol.
Comment 13 linux 2017-04-11 11:35:01 CDT 
The server accepted TLSv1.1. The Illegal parameter alert came from the client. Maybe they couldn't agree on something? I can test it again if required.