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.
Steps to Reproduce:
1. Configure an akonadi IMAP resource to access an SSLv3-only IMAP server
2. Look at nothing at all happening
No user-visible reaction at all.
At least some kind of error message. Ideally, a working IMAP resource.
The IMAP resource has a new maintainer, reassigning to him.
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.
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).
Wishlist item for forcing encryption version https://bugs.kde.org/show_bug.cgi?id=328625
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.
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