Summary: | IMAP resource hangs without error message when server supports SSLv3 only | ||
---|---|---|---|
Product: | [Frameworks and Libraries] Akonadi | Reporter: | Jörg Walter <trouble> |
Component: | IMAP resource | Assignee: | Christian Mollekopf <chrigi_1> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kdepim-bugs, mollekopf, vkrause |
Priority: | NOR | ||
Version: | 4.10 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/kdepimlibs/8f10070603b6ae73de37895ed32d3ae086a0617f | Version Fixed In: |
Description
Jörg Walter
2013-07-15 10:37:23 UTC
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. See also: https://groups.google.com/forum/#!msg/phantomjs/QgwweHYv4HU/odbQxCibzDsJ 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 http://commits.kde.org/kdepimlibs/8f10070603b6ae73de37895ed32d3ae086a0617f |