Bug 322383 - IMAP resource hangs without error message when server supports SSLv3 only
Summary: IMAP resource hangs without error message when server supports SSLv3 only
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Unclassified
Component: IMAP resource (show other bugs)
Version: 4.10
Platform: Ubuntu Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Christian Mollekopf
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-15 10:37 UTC by Jörg Walter
Modified: 2013-12-10 22:24 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jörg Walter 2013-07-15 10:37:23 UTC
Upon connecting to a Lotus Notes/Domino IMAP server via SSL, the IMAP resource simply does nothing, not even update the status message. The IMAP resource status message stays at whatever value it had before trying to connect to the server, and nothing more happens, no CPU usage, no fetching. IMAP resources DID work with KDE 4.8. It stopped working after the upgrade.

ssldump registers connection attempts in some intervals, but connections are dropped immediately after handshake. Further investigation shows that the server only supports SSLv3, not TLS1 (i.e., "openssl s_client ... -ssl3" works, "... -tls1" doesn't). When proxying the connection with stunnel configured as "sslVersion = SSLv3", IMAP works. stunnel fails just the same when leaving out that option.


Reproducible: Always

Steps to Reproduce:
1. Configure an akonadi IMAP resource to access an SSLv3-only IMAP server
2. Look at nothing at all happening
3. Profit?

Actual Results:  
No user-visible reaction at all.

Expected Results:  
At least some kind of error message. Ideally, a working IMAP resource.
Comment 1 Kevin Ottens 2013-11-16 07:34:02 UTC
The IMAP resource has a new maintainer, reassigning to him.
Comment 2 Christian Mollekopf 2013-12-10 13:32:24 UTC
The problem is that we're trying to connect using QSsl::AnyProtocol, which suggests it should be able to connect to sslv3 only server, but actually can't.

The internally used q_SSLv23_client_method (openssl), sends out a SSLv2 client hello message, but will also indicate that it understands sslv3, so the server could upgrade.
However, that doesn't seem to work with sslv3 only servers.

So I think we need to add an explicit sslv3 option, or disable sslv2 right away (AFAIK it's not recommended anyways and sslv3 should be widely supported).

Regarding the error message, I checked that the error is detected internally, so the resource should enter the broken state.

See also:
https://groups.google.com/forum/#!msg/phantomjs/QgwweHYv4HU/odbQxCibzDsJ
Comment 3 Christian Mollekopf 2013-12-10 13:47:57 UTC
According to http://www.openssl.org/docs/ssl/SSL_CTX_new.html q_SSLv23_client_method is the way to go (and what we're using currently), so IMO the server should normally just understand SSLv2 hello messages (even if it then decides to use SSLv3). We could add an option to force a specific ssl version (but probably in a config file only), if that is really required.

For now I'm only concerned about notifying the user that the connection cannot be established. However, I seem to get a dialog when the encryption fails (tested by using plain which is not supported by my server).
Comment 4 Christian Mollekopf 2013-12-10 13:51:19 UTC
Wishlist item for forcing encryption version https://bugs.kde.org/show_bug.cgi?id=328625
Comment 5 Christian Mollekopf 2013-12-10 14:07:55 UTC
The session indeed treats ssl handshake failures the same as other failed attempts to connect to the server and thus doesn't show the dialog that the settings are likely incompatible.
Comment 6 Christian Mollekopf 2013-12-10 22:24:18 UTC
Git commit 8f10070603b6ae73de37895ed32d3ae086a0617f by Christian Mollekopf.
Committed on 10/12/2013 at 21:48.
Pushed by cmollekopf into branch 'master'.

Propagate socket errors to jobs, and don't emit ERR_COULD_NOT_CONNECT on ssl handshake errors.

ssl handshake errors should trigger the dialog to change the settings and not just silently fail.
Unfortunately ssl handshake errors are only detected when trying to connect to a socket without encryption. Otherwise
the error occurs only on the server side and the socket is simply disconnected.

M  +6    -0    kimap/job.cpp
M  +2    -0    kimap/job.h
M  +3    -1    kimap/job_p.h
M  +10   -3    kimap/loginjob.cpp
M  +10   -3    kimap/session.cpp
M  +1    -1    kimap/session_p.h
M  +3    -3    kimap/sessionthread.cpp
M  +2    -2    kimap/sessionthread_p.h
M  +50   -0    kimap/tests/loginjobtest.cpp

http://commits.kde.org/kdepimlibs/8f10070603b6ae73de37895ed32d3ae086a0617f