After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 350617 - [PATCH] Evolution sends IMAP LOGIN even though plaintext authentication is disabled on the server
[PATCH] Evolution sends IMAP LOGIN even though plaintext authentication is di...
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Mailer
1.6.x (obsolete)
Other All
: Urgent critical
: ---
Assigned To: Sankar P
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2006-08-09 16:35 UTC by Andrew Jorgensen
Modified: 2013-09-10 13:42 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Fix (1.05 KB, patch)
2006-08-28 08:57 UTC, Sankar P
none Details | Review
Fix (1.70 KB, patch)
2006-08-28 09:02 UTC, Sankar P
reviewed Details | Review
Fix (2.50 KB, patch)
2006-09-20 08:59 UTC, Sankar P
reviewed Details | Review

Description Andrew Jorgensen 2006-08-09 16:35:38 UTC
Please describe the problem:
If I select TLS encryption for an IMAP connection but I reject the certificate so that it can't use TLS it will fall back to unencrypted and send a plaintext LOGIN even if the server has indicated in the CAPABILITY response that plaintext authentication is disabled

Steps to reproduce:
1. Configure an IMAP server to support TLS with a self-signed certificate
2. Configure Evolution to use TLS as the encryption mechanism
3. Give the password but reject the certificate

Actual results:
Evolution attempts a plaintext LOGIN and an alert is given with a message from the server saying "Plaintext authentication is disabled, but your client sent password in plaintext anyway. If anyone was listening, the password was exposed."

Expected results:
Evolution should see from the CAPABILITY response that LOGIN is not allowed and give up.

Does this happen every time?
Yes

Other information:
Here is the IMAP transaction captured by ethereal:

* OK Dovecot ready.

A00000 CAPABILITY

* CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS LOGINDISABLED

A00000 OK Capability completed.

A00001 LOGIN user password

* BAD [ALERT] Plaintext authentication is disabled, but your client sent password in plaintext anyway. If anyone was listening, the password was exposed.

A00001 NO Plaintext authentication disabled.
Comment 1 Christian Kirbach 2006-08-10 14:59:31 UTC
oO

raising prio
Comment 2 Harish Krishnaswamy 2006-08-28 05:32:41 UTC
This is a must-fix for the release.
Comment 3 Sankar P 2006-08-28 08:57:16 UTC
Created attachment 71751 [details] [review]
Fix

Should probably fix the issue. Needs to be tested and reviewed.
Comment 4 Sankar P 2006-08-28 09:02:18 UTC
Created attachment 71753 [details] [review]
Fix

The previous patch doesnt have the changes in the .h file 

Attaching the correct/complete patch.
Comment 5 Harish Krishnaswamy 2006-09-04 05:53:44 UTC
Sankar : Is this blocked for want of review.
Varadhan : can you please look into this ?
Comment 6 André Klapper 2006-09-04 10:14:57 UTC
patch adds a new string, can only go into 2.8 after request.
Comment 7 parthasarathi susarla 2006-09-10 04:35:11 UTC
This fix works fine. Its ok to commit. sankar, cant this go into the head now??
Comment 8 Harish Krishnaswamy 2006-09-11 04:37:14 UTC
I feel the fix is a Must Have for 2.8 too. 
Sankar : Can you request for a String freeze break and get this in for 2.8 as well.
Comment 9 Sankar P 2006-09-20 08:59:26 UTC
Created attachment 73075 [details] [review]
Fix

The error message in the previous patch was too technical. The new patch has a better error message. Requesting for string break.
Comment 10 Shaun McCance 2006-09-25 17:24:21 UTC
Please use complete sentences:

Failed to connect to IMAP server %s in secure mode, and plain-text password authentication is disabled in the server.
Comment 11 Sankar P 2006-09-27 12:47:00 UTC
Can I commit the patch with changing the string as suggested ?
Comment 12 Harish Krishnaswamy 2006-10-02 14:32:52 UTC
Fix committed by modifying the patch w/o a string change. (using an existing string).
Sankar : Please follow this up again after the release incase you want a more precise error message.