Bug 468795 - Drops back on non-encrypted IMAP when if TLS or SSL encryption is selected
Summary: Drops back on non-encrypted IMAP when if TLS or SSL encryption is selected
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: 10
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-28 01:48 UTC by Henrik Nordström
Modified: 2009-11-18 10:30 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-11-18 10:22:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Henrik Nordström 2008-10-28 01:48:12 UTC
Description of problem:

Seems impossible to get Evolution to use SSL or TLS encrypted IMAP. It starts by using the encrypted connection finding the folderrs, but as soon as you try accessing a folder it drops down to plain-text IMAP communication.

Tested both with TLS and SSL. And with the server port hardcoded in SSL mode. (it still fell back on port 143...)

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

evolution-2.24.1-2.fc10.x86_64

How reproducible:

always

Steps to Reproduce:
1. Configure an IMAP server with TLS or SSL
2. monitor the traffic with wireshark
3. try reading email and watch the traffic in wireshark
  
Actual results:

Silent dropdown to unencrypted IMAP. Lots of unencrypted message exchanges seen in wireshark, including but not limited to acutal mail messages.

Expected results:

That the connection stays encrypted, except for the initial STARTTLS when TLS is selected. Or if it fails on agreeing on the encryption with the server then disconnection and an error message.

Additional info:

My server is using a self-signed certificate, and runs a quite old IMAP software (IMAP4rev1 2001.315rh). I suspect there may be something with the SSL/TLS encryption the two do not agree on.

Comment 1 Milan Crha 2008-11-06 10:35:03 UTC
I tried this with some newer dovecot server and everything seems to work fine.
Try to set the TLS in your account, close Evolution and run this command:
   $ CAMEL_DEBUG=all evolution >& evo.log
connect to the server, view one message and close evolution. Then open file evo.log and search for "tls" in it, there should be lines like:
   received: * OK Dovecot ready.
 (other server here, probably)
   sending : A00000 CAPABILITY

   received: * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND
      UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS QUOTA STARTTLS
      AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5

   received: A00000 OK Capability completed.

   sending : A00001 STARTTLS

   received: A00001 OK Begin TLS negotiation now.

   sending : A00002 CAPABILITY

   ...

When I look in wireshark, everything comes in SSL now on.

I'm not sure, but it seems the changes in the account setup are taking effect after next start of Evolution, did you restart Evolution after turning on/off TLS/SSL? You wrote that some data came encrypted, thus I guess you did, so just mentioning it.

Note: The log contains many information, could even passwords. I do not require it here, but if you consider it'll be better to put here all the log, please strip passwords or other confidential data from it.

Comment 2 Bojan Smojver 2008-11-22 22:15:43 UTC
Seeing the same with evolution-2.24.1.1-1.fc10.i386.

Comment 3 Bojan Smojver 2008-11-23 01:20:38 UTC
BTW, recreation of the account in Preferences does not help with the problem here. Still uses IMAP instead of IMAPS (verified with netstat).

Comment 4 Henrik Nordström 2008-11-25 13:00:14 UTC
Sorry for the delay. Ran the debug trace today, and it looks a bit confused. It's fine up to the CAPABILITY point, but then follows a sequence like the following (after lots of mbox:/home/henrik/.evolition/mail/... accesses):

sending: A00003 AUTHENTICATE CRAM-MD5
received: * XXXXXXX
received: * OK [CAPABILITY ........ and the rest of the server hello]
sending : C00001 CAPABILITY
received: * CAPABILITY [list of capabilities]
received: A00003 OK [CAPABILITY ... ] User Henrik authenticated
sending : A00004 NAMESPACE
received: * (list of namespaces]
received: A00004 OK NAMESPACE completed
CamelException.setc((nil), 303, 'Unexpected OK response from IMAP server: A00003 OK [CAPABILITY ....] User henrik authenticated')

then it continues with C00xx commands, logging in, indexing the mailboxes etc.

The C00xx commands is all seen in plain-text using wireshark.

There is also additional A00XX commands, which all seem to be over the TLS connection.

Regards
Henrik

Comment 5 Bug Zapper 2008-11-26 04:20:46 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Henrik Nordström 2008-12-07 22:15:03 UTC
I can set up a test account on my imap server if you need a server to test against. It supports both STARTTLS and imaps.

Comment 7 Bug Zapper 2009-11-18 08:40:28 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Henrik Nordström 2009-11-18 09:46:18 UTC
Seems to work fine in F12.

Comment 9 Milan Crha 2009-11-18 10:22:30 UTC
Thanks for the update, I'm closing then, but please reopen, if it happens again.

Comment 10 Bojan Smojver 2009-11-18 10:30:53 UTC
(In reply to comment #8)
> Seems to work fine in F12.  

Ditto.


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