Version: 4.6.2 (using KDE 4.6.2)
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:
Datum und Zeit: Montag, 13. Juni 2011 09:34
Zusätzliche Information: tim.rz.rwth-aachen.de: SSL-Aushandlung fehlgeschlagen
Steps to Reproduce:
Access https://tim.rz.rwth-aachen.de/mail-lifecycle/ using Konqueror or reKonq
Patsed error message appears.
Web page opens, as it does in Firefox.
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."
suggestion to Qt to enable such a fallback flag in Qt's SSL code: http://bugreports.qt.nokia.com/browse/QTBUG-19860
(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
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
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.
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.
I've created QTBUG-21906 to track the requirement for access to the compression setting.
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.
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.
(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.
> 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.
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.
M +122 -49 kio/kio/tcpslavebase.cpp
M +0 -3 kio/kio/tcpslavebase.h
Please note that the fix for this bug requires Qt 4.8 or higher.