| Summary: | Konqueror (or tdelibs?) does not support TLSv1.2 | ||
|---|---|---|---|
| Product: | TDE | Reporter: | linux |
| Component: | tdenetwork | Assignee: | Slávek Banko <slavek.banko> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugwatch, linux, michele.calgaro, slavek.banko |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 2696 | ||
| Attachments: | tdelibs : Allow all TLS versions | ||
|
Description
linux
2017-03-31 05:57:52 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? Created attachment 2764 [details]
tdelibs : Allow all TLS versions
Makes sense. Does it fix the problem? (In reply to linux from comment #3) > Makes sense. Does it fix the problem? Yes, the proposed patch is already successfully tested :) 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. 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 :)
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. 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... (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). 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. (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. (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. 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. |