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
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.

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.

https://qt.gitorious.org/~rich/qt/richs-qtbase/commits/ssl-option-config

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.
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

Please note that the fix for this bug requires Qt 4.8 or higher.