Bug 275524 - SSL negotiation with https://tim.rz.rwth-aachen.de/mail-lifecycle/ fails (works with Firefox)
Summary: SSL negotiation with https://tim.rz.rwth-aachen.de/mail-lifecycle/ fails (wor...
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: 4.6.2
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-13 09:38 UTC by Gunter Ohrner
Modified: 2012-06-06 01:21 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8.4


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gunter Ohrner 2011-06-13 09:38:52 UTC
Version:           4.6.2 (using KDE 4.6.2) 
OS:                Linux

Trying to access https://tim.rz.rwth-aachen.de/mail-lifecycle/ results in:

Die Aktion lässt sich nicht ausführen
Verbindungsaufbau vom Server abgelehnt

Details der Anfrage:
Adresse: https://tim.rz.rwth-aachen.de/mail-lifecycle/
Protokoll: https
Datum und Zeit: Montag, 13. Juni 2011 09:34
Zusätzliche Information: tim.rz.rwth-aachen.de: SSL-Aushandlung fehlgeschlagen

Reproducible: Always

Steps to Reproduce:
Access https://tim.rz.rwth-aachen.de/mail-lifecycle/ using Konqueror or reKonq

Actual Results:  
Patsed error message appears.

Expected Results:  
Web page opens, as it does in Firefox.
Comment 1 Richard Moore 2011-06-13 16:27:21 UTC
This server has a number of configuration errors, and bugs. The reason KIO is having trouble connecting appears to be because it will not accept connections that support TLS1 even when they use the SSL3 compatible handshake:

openssl s_client -connect  tim.rz.rwth-aachen.de:443 -ssl3 FAILS

openssl s_client -connect  tim.rz.rwth-aachen.de:443 -tls1 FAILS

openssl s_client -connect  tim.rz.rwth-aachen.de:443  -no_tls1 WORKS

It also has SSL2 enabled which is bad.

It also has NULL ciphers enabled which is very bad.

Basically KDE should be able to connect to this by using more work arounds, but the underlying problem is a buggy server. eg. if you look in Google Chrome on windows you'll see this message:

 "The connection had to be retried using SSL 3.0. This typically means that the server is using very old software and may have other security issues. The server does not support the TLS renegotiation extension."
Comment 2 8mhr-t6m2 2011-06-14 12:16:29 UTC
suggestion to Qt to enable such a fallback flag in Qt's SSL code: http://bugreports.qt.nokia.com/browse/QTBUG-19860
Comment 3 Dawit Alemayehu 2011-10-08 14:31:03 UTC
(In reply to comment #1)
> This server has a number of configuration errors, and bugs. The reason KIO is
> having trouble connecting appears to be because it will not accept connections
> that support TLS1 even when they use the SSL3 compatible handshake:
> 
> openssl s_client -connect  tim.rz.rwth-aachen.de:443 -ssl3 FAILS
> 
> openssl s_client -connect  tim.rz.rwth-aachen.de:443 -tls1 FAILS
> 
> openssl s_client -connect  tim.rz.rwth-aachen.de:443  -no_tls1 WORKS

This does not seem to work either. At least it does not work on my system. I get the following when I try it:

$ openssl s_client -connect  tim.rz.rwth-aachen.de:443  -no_tls1
CONNECTED(00000003)
139725117707944:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 141 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

The only thing that works with this site is SSLv2:
openssl s_client -connect  tim.rz.rwth-aachen.de:443  -ssl2

What I find curious is that both Chromium and Firefox seem to connect to the site using SSLv3 handshake, at least that is what they report. Therefore I do not understand why that won't work with either QtNetwork or openssl's command line client.
Comment 4 Richard Moore 2011-10-08 15:39:17 UTC
Indeed, using openssl 1.0.0c I see the same as you, I can only connect using SSL2. Examining the track in wireshark, the server FINs the connection immediately after getting the CLIENT HELLO message. Examining the HELLO I see I'm sending 45 ciphers suites, and 2 compression methods. Unfortunately s_client doesn't let us disable compression, however I built openssl 1.0.0d with no-zlib and forced ssl3 and was then able to connect.

The reason it likely worked in my earlier attempt (comment #1) was because I was using an older openssl that had no support for compression. So, the problem is still a buggy server however we can probably work around it using the SSL_OP_NO_COMPRESSION flag.
Comment 5 Richard Moore 2011-10-08 15:50:22 UTC
I've created QTBUG-21906 to track the requirement for access to the compression setting.
Comment 6 Richard Moore 2011-10-09 21:11:25 UTC
I've implemented most of what's needed to resolve this for Qt5, but it still needs autotests etc. before I can make the MR.

https://qt.gitorious.org/~rich/qt/richs-qtbase/commits/ssl-option-config
Comment 7 Richard Moore 2011-10-11 08:58:35 UTC
Just an update that s_client does in fact have a no compression option, it just isn't listed in the usage. It's -no_comp as I discovered when I looked at adding this to openssl.
Comment 8 Dawit Alemayehu 2011-10-15 03:15:43 UTC
(In reply to comment #7)
> Just an update that s_client does in fact have a no compression option, it just
> isn't listed in the usage. It's -no_comp as I discovered when I looked at
> adding this to openssl.

Indeed. The -ssl3 or even -no_tls1 works fine when used with -no_comp ; so the problem with that site is not only its missing support for TLS1 but also the fact that it does not support SSL compression. 

BTW, your patch seems to be for Qt5, but this is actually a bug in Qt's networking code. As such should it not be addressed in Qt 4.8 at the least ? I personally think this would even qualify to be fixed in Qt 4.7.x simply because no one knows how many such sites exist out in the wild.
Comment 9 Richard Moore 2011-10-19 13:22:16 UTC
> BTW, your patch seems to be for Qt5, but this is actually a bug in Qt's
> networking code. As such should it not be addressed in Qt 4.8 at the least ?

Yes, it's been accepted for qt5 and i've also asked for it to be backported. Peter seems basically in agreement that it should be.
Comment 10 Dawit Alemayehu 2012-05-30 06:32:28 UTC
Git commit d2754fa03025be9324e4d652428eee2c4ca2d4fb by Dawit Alemayehu.
Committed on 19/05/2012 at 08:07.
Pushed by adawit into branch 'KDE/4.8'.

- Fixed SSL negotiation failure when connecting secure sites that do not support
  SSL compression, e.g. https://tim.rz.rwth-aachen.de/mail-lifecycle/.

- Use KTcpSocket::SecureProtocols instead of KTcpSocket:TlsV1 as the default SSL
  protocol. This fixes very slow connections to certain sites, e.g. "Search for Jobs"
  button @ http://www.suse.com/company/careers/.

- Improve the speed of SSL negotiation by caching and sharing the previous
  settings amongst ioslaves when those settings are not the default ones.
  That way any ioslave that connects to the same host afterwards does not
  have to perform the same expensive SSL negotiation process all over again.
FIXED-IN: 4.8.4
REVIEW: 103610

M  +122  -49   kio/kio/tcpslavebase.cpp
M  +0    -3    kio/kio/tcpslavebase.h

http://commits.kde.org/kdelibs/d2754fa03025be9324e4d652428eee2c4ca2d4fb
Comment 11 Dawit Alemayehu 2012-06-06 01:21:59 UTC
Please note that the fix for this bug requires Qt 4.8 or higher.