Bug 14425 - EVOLUTION suffers the POODLE SSLv3 Problem calling IMAP
Summary: EVOLUTION suffers the POODLE SSLv3 Problem calling IMAP
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 4
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact:
Whiteboard: advisory mga4-32-ok mga4-64-ok
Keywords: validated_update
Depends on:
Reported: 2014-11-01 12:43 CET by Jürgen Kowalzik
Modified: 2014-12-05 16:54 CET (History)
4 users (show)

See Also:
Source RPM: evolution-data-server-3.10.2-1.mga4.src.rpm
Status comment:


Description Jürgen Kowalzik 2014-11-01 12:43:13 CET
Description of problem:
I can't get mail from an IMAP-Server

Version-Release number of selected component (if applicable):

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:
2. E-Mail abrufen

The Problem is well known:
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


Steps to Reproduce:
Comment 1 Jürgen Kowalzik 2014-11-01 12:49:02 CET
Comment 2 Florian Hubold 2014-11-01 16:49:34 CET
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.

CC: (none) => doktor5000, olav
Assignee: bugsquad => doktor5000
Source 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

Florian Hubold 2014-11-01 16:50:17 CET

Whiteboard: (none) => MGA3TOO

David Walser 2014-11-01 17:13:58 CET

QA Contact: security => (none)

Comment 3 Olivier Delaune 2014-11-23 22:47:11 CET
Jürgen, did you try the packages available in updates_testing? Do they solved your problem?

CC: (none) => olivier.delaune

Comment 4 Florian Hubold 2014-11-23 23:53:47 CET
No feedback since 3 weeks, pinged him again in german forum:
Comment 5 Olivier Delaune 2014-11-26 21:03:24 CET
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).
Comment 6 Florian Hubold 2014-11-27 00:20:43 CET
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?
Comment 7 Olivier Delaune 2014-11-27 07:16:07 CET
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)?
Comment 8 David Walser 2014-11-29 23:31:53 CET
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

Comment 9 Florian Hubold 2014-11-30 00:09:33 CET
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.
Comment 10 Florian Hubold 2014-11-30 20:33:39 CET
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:


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




List of packages to validate




Assignee: doktor5000 => qa-bugs
Whiteboard: MGA3TOO => (none)

Comment 11 Jürgen Kowalzik 2014-12-01 14:08:43 CET
Now Evolution is working well, but...

a) it works, when you open a new user whit the e-mail-accout
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 :(

Comment 12 Florian Hubold 2014-12-04 01:33:15 CET
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?
Comment 13 claire robinson 2014-12-04 09:33:15 CET
Thanks for testing Jürgen. Did you test on i586 or x86_64 please?
Comment 14 Florian Hubold 2014-12-04 13:11:09 CET
(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
Comment 15 claire robinson 2014-12-04 22:41:00 CET
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

Comment 16 claire robinson 2014-12-04 22:50:59 CET
Validating. Advisory uploaded.

Could sysadmin please push to updates


Keywords: (none) => validated_update
Whiteboard: mga4-32-ok mga4-64-ok => advisory mga4-32-ok mga4-64-ok
CC: (none) => sysadmin-bugs

Comment 17 Mageia Robot 2014-12-05 16:54:47 CET
An update for this issue has been pushed to Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.