Description of problem: I can't get mail from an IMAP-Server Version-Release number of selected component (if applicable): evolution-3.10.2-1 How reproducible: Even I choose STARTTLS Port 993 a red window appears: "Ordner konnte nicht geöffnet werden. The reported error was "Verbindung mit »secureimap.t-online.de:993« gescheitert Cannot communicate sewrely with peer: no common encryption algorithm(s)."." Steps to Reproduce: 1. open EVOLUTION 2. E-Mail abrufen 3. The Problem is well known: http://www.heise.de/security/meldung/SSL-Verschluesselung-Noch-viel-Arbeit-fuer-Mail-Provider-und-Banken-2429414.html http://www.novell.com/support/kb/doc.php?id=7015773 "Evolution If your email server supports the STARTTLS (http://en.wikipedia.org/wiki/STARTTLS) feature, we suggest you change configuration on Evolution email client from "SSL" to "TLS". This will force Evolution email client to use STARTTLS over plain SSL. SUSE is currently working on using TLS instead of SSLv3 when "SSL" is chosen in the configuration dialog, for mail servers not supporting STARTTLS. A respective patch will be available in the future." This message is not usefull with IMAP t-online.de These distribution tries to solve the problem: https://www.centos.org/forums/viewtopic ... 48&t=49252 https://bugzilla.redhat.com/show_bug.cgi?id=1153723 Reproducible: Steps to Reproduce:
https://www.centos.org/forums/viewtopic.php?f=48&t=49252
Added the patch from https://bugzilla.redhat.com/show_bug.cgi?id=1153052, submitted evolution-data-server-3.10.2-1.1.mga4 to core/updates_testing - should be available on mirrors soon.
Status: NEW => ASSIGNEDCC: (none) => doktor5000, olavAssignee: bugsquad => doktor5000Source RPM: evolution-3.10.2-1.mga4.x86_64.rpm 10-Nov-2013 17:37 9.8M evolution-data-server-3.10.2-1.mga4.x86_64.rpm 10-Nov-2013 17:23 1.4M => evolution-data-server-3.10.2-1.mga4.src.rpm
Whiteboard: (none) => MGA3TOO
QA Contact: security => (none)
Jürgen, did you try the packages available in updates_testing? Do they solved your problem?
CC: (none) => olivier.delaune
No feedback since 3 weeks, pinged him again in german forum: https://forums.mageia.org/de/viewtopic.php?p=25942#p25942
Jürgen answered me by email. In summary, it does not solve his problem. See https://forums.mageia.org/de/viewtopic.php?f=5&t=2306&start=25 (if you speak German).
That's the same thread I linked to previously, where I discussed this with him. Problem is currently that Evolution is unusable for him as it only asks for the password when you exit it. It is unrelated to this issue, and those update candidates here cannot fix that issue. Should I assign it to QA nevertheless?
Ok, maybe you can assign it to QA. But first, could you describe step by step how to reproduce the problem (I do not understand the German in the Jürgen's first post)?
Before assigning to QA, can you define what problem the update is fixing (and whether the update actually fixes it)? That's not clear from reading this bug report.
Component: Security => RPM Packages
Yes, I will definitely - once I get around to define that clearly, as the upstream bug reports are not really consistent regarding STARTTLS absence or SSL absence or weird combinations ... the original issue the Fedora bug seemed to be targeted at was mail providers that disabled SSL support in raction to Poodle, and whose mail servers did not announce and/or support STARTTLS - the patch would enable and go through all of the remaining encryptions in NSS and then use what is left ... AFAIU. And also some international or at least english mail provider that is still affected, to reproduce this.
After some reading and testing, think I nailed it now. Suggested advisory follows, including some in-depth test instructions regarding SSLv3 and STARTTLS (not sure if that should also be in the advisory, I've no objections against that). I've left instructions for SMTP out, as this should be fixed now too, when the conditions are met. I've also submitted an updated evolution-data-server-3.10.2-1.2.mga4 which uses the current patch provided by RedHat and adds some comments on the conditions where it would fail without the patch. And removed the MGA3TOO flag as that's EOL. ---- Evolution in the default configuration is not able to use TLSv1 or higher for SSL connections - it only allows SSLv3 connections. When TLS is enabled in Evolution, it requires the server to support STARTTLS, which is not offered by all servers. Hence Evolution will fail on all servers where SSLv3 has been disabled after the recent POODLE vulnerability. This is mainly an issue for connecting to IMAP servers, but may also apply to POP3 or SMTP servers. Steps to Reproduce: 1. Try to connect to a server that doesn't allow SSLv3 and which does not support STARTTLS 2. Evolution can't connect and fails with an error message: "Cannot communicate securely with peer: no common encryption algorithm(s)." # detailed test instructions for SSLv3 and STARTTLS support- server configuration regarding SSLv3 can be verified via openssl s_client as follows: server_imap=secureimap.t-online.de #test IMAP via SSL (defaults to port 993) (remove -quiet for more verbose output) #explicitly test only with sslv3 allowed - should result in: ## "[...] sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40[...]" openssl s_client -connect ${server_imap}:993 -ssl3 -quiet #explicitly test with everything except sslv3 (only for completeness sake) openssl s_client -connect ${server_imap}:993 -no_ssl3 -quiet Expected results when SSLv3 is disabled: > 140037873890960:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40 > 140037873890960:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: SSL alert number 40 is a fatal handshake failure as described in http://tools.ietf.org/html/rfc5246#appendix-A.3 #test explicitly for starttls via default imap port 143 openssl s_client -connect ${server_imap}:143 -starttls imap -crlf -quiet Expected results when STARTTLS is not supported by the server > didn't found STARTTLS in server response, try anyway... > write:errno=32 When the two above conditions are met, Evolution would previously simply fail. Now it should be able to connect, as it will try all available SSL/TLS algorithms provided by the currently installed NSS version. References: https://bugzilla.redhat.com/show_bug.cgi?id=1153052 http://pkgs.fedoraproject.org/cgit/evolution-data-server.git/commit/?h=f19&id=0b1a3991e3afc6ff60bbcbb75ea3e3d8fdf16829 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765838 ---- List of packages to validate i586 evolution-data-server-3.10.2-1.2.mga4.i586 libcamel1.2_45-3.10.2-1.2.mga4.i586 libebackend1.2_7-3.10.2-1.2.mga4.i586 libebook-contacts1.2_0-3.10.2-1.2.mga4.i586 libebook1.2_14-3.10.2-1.2.mga4.i586 libecal1.2_16-3.10.2-1.2.mga4.i586 libedata-book1.2_20-3.10.2-1.2.mga4.i586 libedata-cal1.2_23-3.10.2-1.2.mga4.i586 libedataserver1.2-devel-3.10.2-1.2.mga4.i586 libedataserver1.2_18-3.10.2-1.2.mga4.i586 libevolution-data-server-gir1.2-3.10.2-1.2.mga4.i586 x86_64 evolution-data-server-3.10.2-1.2.mga4.x86_64 lib64camel1.2_45-3.10.2-1.2.mga4.x86_64 lib64ebackend1.2_7-3.10.2-1.2.mga4.x86_64 lib64ebook-contacts1.2_0-3.10.2-1.2.mga4.x86_64 lib64ebook1.2_14-3.10.2-1.2.mga4.x86_64 lib64ecal1.2_16-3.10.2-1.2.mga4.x86_64 lib64edata-book1.2_20-3.10.2-1.2.mga4.x86_64 lib64edata-cal1.2_23-3.10.2-1.2.mga4.x86_64 lib64edataserver1.2-devel-3.10.2-1.2.mga4.x86_64 lib64edataserver1.2_18-3.10.2-1.2.mga4.x86_64 lib64evolution-data-server-gir1.2-3.10.2-1.2.mga4.x86_64 SRPMS evolution-data-server-3.10.2-1.2.mga4.src
Assignee: doktor5000 => qa-bugsWhiteboard: MGA3TOO => (none)
Hi! Now Evolution is working well, but... a) it works, when you open a new user whit the e-mail-accout https://forums.mageia.org/de/viewtopic.php?f=5&t=2306&p=26008#p26008 b) my old user "juergen" has still a miss-configurated Evolution e-mail-accout (IMAP t-online.de) POP3 is running (cityweb.de) c) it also runs, if you have a laptop, never used the last 3 month, you start it now, make all updates an then starts Evolution :( https://forums.mageia.org/de/viewtopic.php?f=5&t=2306&p=26008#p26004 greetings J.
To sum it up, Juergen is now able to fetch mails via IMAP again, after SSLv3 was disabled, so the update is effective. Can we please get this validated?
Thanks for testing Jürgen. Did you test on i586 or x86_64 please?
(In reply to claire robinson from comment #13) > Thanks for testing Jürgen. Did you test on i586 or x86_64 please? x86_64, I'd say: https://forums.mageia.org/de/viewtopic.php?p=25968#p25968
Jürgen got in touch via email to say he'd tested both i586 and x86_64 so I'll add the OK's and validate this one.
Whiteboard: (none) => mga4-32-ok mga4-64-ok
Validating. Advisory uploaded. Could sysadmin please push to updates Thanks
Keywords: (none) => validated_updateWhiteboard: mga4-32-ok mga4-64-ok => advisory mga4-32-ok mga4-64-okCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2014-0210.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED