Bug 3024

HTTPS in Konqueror stopped working after another reboot. Also KWeather stopped working. Seems that SSL works somehow randomly. There are no problems in other applications (Otter Browser, Links).

You see some information about SSL listed in ~/.xsession-errors?

Just as info, I have used TDE R14.1.0-dev version on buster for a long time, didn't notice any issue with SSL and TLS.

No SSL in ~/.xsession-errors?

Attempt to open https://kernel.org in Konqeuror as seen by Wireshark - note that len is always 0 - no data transferred, TLS not even started.

No.     Time           Source                Destination           Protocol Length Info
    441 158.364809171  192.168.0.253         198.145.29.83         TCP      74     59774 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1440430212 TSecr=0 WS=64
Transmission Control Protocol, Src Port: 59774, Dst Port: 443, Seq: 0, Len: 0
    442 158.521485751  198.145.29.83         192.168.0.253         TCP      74     443 → 59774 [SYN, ACK] Seq=0 Ack=1 Win=43440 Len=0 MSS=1440 TSval=1903252700 TSecr=1440430212 WS=2048
Transmission Control Protocol, Src Port: 443, Dst Port: 59774, Seq: 0, Ack: 1, Len: 0
    443 158.521606438  192.168.0.253         198.145.29.83         TCP      66     59774 → 443 [ACK] Seq=1 Ack=1 Win=29248 Len=0 TSval=1440430368 TSecr=1903252700
Transmission Control Protocol, Src Port: 59774, Dst Port: 443, Seq: 1, Ack: 1, Len: 0
    444 158.533489959  192.168.0.253         198.145.29.83         TCP      66     59774 → 443 [FIN, ACK] Seq=1 Ack=1 Win=29248 Len=0 TSval=1440430380 TSecr=1903252700
Transmission Control Protocol, Src Port: 59774, Dst Port: 443, Seq: 1, Ack: 1, Len: 0
    445 158.696809096  198.145.29.83         192.168.0.253         TCP      66     443 → 59774 [FIN, ACK] Seq=1 Ack=2 Win=45056 Len=0 TSval=1903252874 TSecr=1440430380
Transmission Control Protocol, Src Port: 443, Dst Port: 59774, Seq: 1, Ack: 2, Len: 0
    446 158.696913300  192.168.0.253         198.145.29.83         TCP      66     59774 → 443 [ACK] Seq=2 Ack=2 Win=29248 Len=0 TSval=1440430544 TSecr=1903252874
Transmission Control Protocol, Src Port: 59774, Dst Port: 443, Seq: 2, Ack: 2, Len: 0

No info about SSL ~/.xsession-errors

Upgraded another Stretch system - a testing one. No KMail accounts configured there but SSL does not work in Konqueror. Each HTTPS access ends with "Could not connect to host". Both affected systems are 32-bit.

One 64-bit system seems to work fine. Maybe it's limited to i386 build?

I am seeing the same (or a very similar) problem on a 64bit system. KMail also can't fetch mail from IMAP servers, reporting a TLS starting error. Also, I can't send mail via SMTP servers that require SSL. I can, however, visit https://www.kernel.org without any problems in Konqueror. My .xsession-errors says:

140363750851840:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too 
small:../ssl/statem/statem_clnt.c:2156:
[2019/07/17 17:21:48.030] [tdeio_imap] WARNING: TLS mode setup has failed.  Aborting.

I experience similar problem after upgrade Stretch to Buster.

I use multiple POP3 accounts. Next message is printed by Trinity KMail

Could not connect to host Your POP3 server claims to support TLS but negotiation was unsuccessful. You can disable TLS in TDE using the crypto settings module.

~/.xsession-errors reveals

139677825209600:error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol:../ssl/statem/statem_lib.c:1922

May be some more info can help.

In TDE Center Crypto module I have enabled SSL -> TLS

When I try switch Cypher Wizard to Enable All and close the center and open it again then Cypher Wizard box is empty.

If I try test in OpenSSL tab then

OpenSSL was successfully loaded.

is reported.

I have POP3 servers matching entries with cached certificates in Peer SSL certificates. I have removed them. When I try to test for account features in KMail, no certificate appears in the cache.

When I connect by Kopete to my Jabber account, I see

The certificate of server XXX could not be validated for account XXXX: An unknown error occurred trying to validate the certificate.
Do you want to continue?

If I press continue then Kopete connect to account, I see other colleges marked active.

The problem solved, Debian changed minimal required protocol version

https://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#openssl-defaults

5.1.7. OpenSSL default version and security level raised

Next change in /etc solves the problem for me in Kmail and Kopete

diff --git a/ssl/openssl.cnf b/ssl/openssl.cnf
index a6fed92..b51fc17 100644
--- a/ssl/openssl.cnf
+++ b/ssl/openssl.cnf
@@ -358,5 +358,5 @@ ssl_conf = ssl_sect
 system_default = system_default_sect

 [system_default_sect]
-MinProtocol = TLSv1.2
-CipherString = DEFAULT@SECLEVEL=2
+MinProtocol = None
+CipherString = DEFAULT

My problem is not related to OpenSSL configuration - already tried that configuration change.

I can confirm that changing OpenSSL config resolves my problems with KMail (sending via SSL, receiving via TLS).

So looks like 64-bit is unaffected.

A weird thing: when I hit F5 repeatedly in Konqueror, the HTTPS web finally opens. Also sending an e-mail with starttls failed but finally succeeded after repeating "Send Queued Messages" and "killall tdeio_smtp".

The bug is trivial to reproduce:
1. Do a clean install of i386 Buster (minimal)
2. apt install wget gnupg && wget http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-keyring.deb && dpkg -i trinity-keyring.deb
4. echo "deb http://mirror.xcer.cz/trinity-sb buster deps-r14 main-r14" >/etc/apt/sources.list.d/trinity.list && apt update
5. apt update && apt install tdebase-trinity tdm-trinity xserver-xorg
6. service tdm start
7. login, launch Konqueror and open any HTTPS site (such as https://kernel.org)

Did the same with AMD64 Buster and HTTPS works.

Did another test: installed i386 Buster and TDE 14.0.6 for Stretch. HTTPS works fine!

Right now, a colleague tried on a cleanly installed Buster@amd64 to set up an IMAPs account into KMail and encountered an SSL problem. An attempt to use openssl s_client in the command line confirmed that the problem is in a more strict default OpenSSL configuration with which a particular server was not accepted. See:

https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#openssl-defaults

After a change in the OpenSSL configuration file, the openssl client in the command line successfully connected. Likewise, access to IMAPs from KMail began to work.

Therefore, I am still not sure if we can consider it as confirmed that this is a problem in TDE.

I can confirm Konqueror is sometimes unable to open https websites, exactly as described in the OP. Curiously, some attempts on the same website success, while some fail.

Debian Buster / TDE R14.0.7 PSB fresh install.

(In reply to Q4OS Team from comment #19)
> I can confirm Konqueror is sometimes unable to open https websites, exactly
> as described in the OP. Curiously, some attempts on the same website
> success, while some fail.
> 
> Debian Buster / TDE R14.0.7 PSB fresh install.

The observed results are without change in the default openssl configuration in /etc or with the changes as mentioned in Debian Relase Notes?

(In reply to Slávek Banko from comment #20)
> The observed results are without change in the default openssl configuration
> in /etc or with the changes as mentioned in Debian Relase Notes?

This is a fresh Buster/TDE installation, default configuration.

(In reply to Q4OS Team from comment #21)
> (In reply to Slávek Banko from comment #20)
> > The observed results are without change in the default openssl configuration
> > in /etc or with the changes as mentioned in Debian Relase Notes?
> 
> This is a fresh Buster/TDE installation, default configuration.

Please, can you run a second test with a modified OpenSSL configuration?

(In reply to Slávek Banko from comment #22)
> Please, can you run a second test with a modified OpenSSL configuration?
Yes, however it could take awhile as I screwed the original installation heavily. I will post a result here as I make a new testing install.

Repeating once more: this bug is present only on i386 and is NOT related to openssl configuration. I did clean installs of i386 and amd64 Buster on the same machine. amd64 works fine, i386 is broken.

(In reply to linux from comment #24)
> Repeating once more: this bug is present only on i386 and is NOT related to
> openssl configuration. I did clean installs of i386 and amd64 Buster on the
> same machine. amd64 works fine, i386 is broken.
Yes, my testing results above came from i386 system. Although it arises mostly on i386 systems, I have noticed that on an 64bit installation in rare cases as well.

(In reply to linux from comment #24)
> Repeating once more: this bug is present only on i386 and is NOT related to
> openssl configuration. I did clean installs of i386 and amd64 Buster on the
> same machine. amd64 works fine, i386 is broken.

As I mentioned in comment 18, I had the same problem observed on AMD64 architecture, and there apparently was the problem caused by the OpenSSL configuration. Also in other posts it is seen that this is not clearly related exclusively to i386, but is also observed on amd64.

Please, on a machine where you are reliably observing the problem, you can try initializing the connection using "openssl s_client -connect your-imap-server:993" or "openssl s_client -starttls imap -connect your-imap-server:143" in the cli?

Created attachment 2925 [details]
Screenshot of Konqueror and openssl s_client

Attached a screenshot of Konqueror unable to connect to https://www.trinitydesktop.org and openssl s_client connected to the same host.

(In reply to linux from comment #27)
> Created attachment 2925 [details]
> Screenshot of Konqueror and openssl s_client
> 
> Attached a screenshot of Konqueror unable to connect to
> https://www.trinitydesktop.org and openssl s_client connected to the same
> host.

Excellent, thank you.

For now I have one suspicion – for the OPENSSL_init_ssl and OPENSSL_init_crypto functions, we use the ulong (32bit) type for the first argument, while correctly it should be uint64_t (64bit). See:

https://mirror.git.trinitydesktop.org/gitea/TDE/tdelibs/src/branch/master/tdeio/kssl/kopenssl.cc#L660

Looks plausible. Openssl gets some random crap in half of the first argument. That would explain the random behavior.

Result of a new testing, Debian Buster 32bit default configuration / TDE 14.0.7 PSB / Virtualbox 5.2:
Random success opening https sites in Konqueror circa 50/50 as described before.

After configuring /etc/ssl/openssl.cnf:

 [system_default_sect]
MinProtocol = None
CipherString = DEFAULT

No change, Konqueror still fails to open https sites randomly, even after reboot.

(In reply to Q4OS Team from comment #30)
> Result of a new testing, Debian Buster 32bit default configuration / TDE
> 14.0.7 PSB / Virtualbox 5.2:
> Random success opening https sites in Konqueror circa 50/50 as described
> before.
> 
> After configuring /etc/ssl/openssl.cnf:
> 
>  [system_default_sect]
> MinProtocol = None
> CipherString = DEFAULT
> 
> No change, Konqueror still fails to open https sites randomly, even after
> reboot.

Thank you for performing the tests and confirming the observed results.

Please, can you do tests again with tdelibs14-trinity >= 4:14.0.7~pre25-0debian10.0.1+5?

Just upgraded to 4:14.0.7~pre25-0debian10.0.1+5 - no change in behavior, still broken the same way.

(In reply to linux from comment #33)
> Just upgraded to 4:14.0.7~pre25-0debian10.0.1+5 - no change in behavior,
> still broken the same way.

Oh, oh, my fault - I wanted to add an additional patch for test, but I did it wrong == no patch was added.  I'll prepare another update... stay tuned.

Please, you can do tests again with tdelibs14-trinity >= 4:14.0.7~pre25-0debian10.0.2+5?

Konqueror now works fine with HTTPS, great! Thank you.

(In reply to linux from comment #36)
> Konqueror now works fine with HTTPS, great! Thank you.

Great, thank you. @Q4OS Team - can you also confirm that the behavior is also good on your test machines?

I am not able to reproduce the bug with the recent TDE R14.0.7 anymore. Looks to be fixed, thanks.

Fixed by commits a2ad929640 (master), 68f3283bf4 (r14.0.x) and 8a26a48f42 (v3.5.13-sru).

Thank you for reporting and collaborating on the solution!

KMail works fine too.