GNOME Bugzilla – Bug 336543
Problem with TLS support
Last modified: 2012-04-20 04:02:03 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/evolution/+bug/23548 "I've setup evolution to use TLS authentication to fetch mail, but logcheck gives this error on the pop server: System Events =-=-=-=-=-=-= Oct 8 14:59:54 localhost courierpop3login: couriertls: accept: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number This thread on evolution-list may give some tips about this: http://mail.gnome.org/archives/evolution-list/2005-May/msg00017.html Apparently this problem is corrected on evolution, but maybe could be an ubuntu problem related to the linked libraries... Thanks. ... > Thanks for your bug. What version of Ubuntu do you use? ... I'm using Breezy Badger with last packages. Ask for whatever you need :) ... > Do you still have that issue? ... Yes, it still fails. evolution can start correctly a plain session and a SSL session, but it can't stablish a TLS session. ... >> You could run evolution with CAMEL_DEBUG=all and attach the output as a file to this bug - maybe we can get closer to what actually goes wrong. ... http://librarian.launchpad.net/1512109/tls-log Created an attachment (id=5638) Log with CAMEL_DEBUG=all set I've cut just the "fetching mail" part. If it's needed the full log, I can send it too needed info attached"
hmm... if you want to use tls, you can try to explicitly set the port number, e.g. imap.example.com:143
I think it's something related to http://bugzilla.gnome.org/show_bug.cgi?id=339903 With latest evolution (2.6.1) I get this message: "Error while Fetching Mail. Failed to connect to POP server pop.mailhost.com in secure mode: SSL negotiations failed" Then, the problem seems to be on the server or the library which tries to connect with the server. It is a problem that I suffer since one year or two...
BTW, my POP server works OK with TLS in other mail clients.
Another Ubuntu comment: STARTTLS support in evolution seems to be broken; I just did a capture with evolution talking to a TLS enabled server; * OK IMAP4 Ready woodchuck 00023754 A00000 CAPABILITY * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS A00000 OK CAPABILITY A00001 STARTTLS A00001 OK Begin TLS negotiation now A00002 LOGIN cs1ajb my-password-in-the-clear It looks like evolution never bothers to do the TLS negotiation and just starts talking in the clear.
I can't reproduce this latest comment... perhaps your SSL libraries don't work? I have no idea... how are you getting this "trace"? CAMEL_DEBUG? If so, CAMEL_DEBUG output won't show that the stream is encrypted because it prints the date before/after encryption/decryption takes place, so as to actually be useful to us developers trying to read the protocol log :)
any news here? still an issue?
I couldn't get an answer from the original reporter, but these comments crept up since then: " This bug had not been an issue for me in Dapper, but has popped up in Edgy. At issue is a connection to a courier imap server using TLS authentication. Evolution gives the error: "Failed to connect to IMAP server [server.address] in secure mode: SSL negotiations failed" On the server side, Courier logs: "couriertls: accept: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number". Courier is running on Debian Stable (Sarge), and is up to date. The IMAP server certificate is of the self-signed lazy "let courier set it up" variety. Thunderbird continues to connect using TLS correctly. Let me know if there's any other info I can provide to help with this! P.S. As I mentioned above, I had been using the lazy ("localhost") courier cert for TLS authentication. Worth noting that even after switching to a self-signed cert for the correct server address, I have the same issue. " " I have similar behaviour with Evolution (Dapper) talking to my Debian server using uw-imapd. In my case plaintext passwords are disabled on the server outside of TLS, and after attempting a STARTTLS command evolution backs off to CRAM-MD5 without encryption. The notes in the server log: Oct 24 13:51:48 guinness imapd[31748]: connect from 64.26.x.y (64.26.x.y) Oct 24 13:51:48 guinness imapd[31748]: imap service init from 64.26.x.y Oct 24 13:51:48 guinness imapd[31748]: Unable to accept SSL connection, host=ottawa-hs-64-26-x-y.d-ip.magma.ca [64.26.x.y] Oct 24 13:51:48 guinness imapd[31748]: SSL error status: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Oct 24 13:51:48 guinness imapd[31749]: connect from 64.26.x.y (64.26.x.y) Oct 24 13:51:48 guinness imapd[31749]: imap service init from 64.26.x.y Oct 24 13:51:49 guinness imapd[31749]: Authenticated user=myusername host=ottawa-hs-64-26-x-y.d-ip.magma.ca [64.26.x.y] "
bug #345135 is similar to that one with useful informations too
I'm the original reporter ( hi Daniel :) ), I recently upgraded to Edgy Eft (evolution 2.8.1) and I keep getting the error. When configuring my account, evolution can't check the server for supported types. It says: Error while Checking Service. Could not connect to POP server pop.warp.es But evolution has connected to the server and has tried to start a TLS conversation: +OK Hello there. CAPA +OK Here's what I can do: STLS TOP USER LOGIN-DELAY 10 PIPELINING UIDL IMPLEMENTATION Courier Mail Server . STLS +OK Begin SSL/TLS negotiation now. .4................. ........d..b.........].e.[`.Da0G.d And then, it shows the previous error. When I try to fetch my email, I get this: Error while Fetching Mail. Failed to connect to POP server pop.warp.es in secure mode: TLS negotiations failed And wireshark shows a connection log similar to the previous one. What info or traces can I send to this bug to help?
confirming as per duplicates, i'd say
Anyone see any progress? I get no luck changing the STARTTLS option: katie:/etc/courier# cat imapd-ssl | egrep -v '(#|$^)' SSLPORT=993 SSLADDRESS=0 SSLPIDFILE=/var/run/courier/imapd-ssl.pid IMAPDSSLSTART=YES IMAPDSTARTTLS=YES IMAP_TLS_REQUIRED=0 COURIERTLS=/usr/bin/couriertls TLS_PROTOCOL=TLS1 TLS_STARTTLS_PROTOCOL=SSL3 TLS_CERTFILE=/etc/certs/secure.linknet.se.pem TLS_TRUSTCERTS=/etc/certs/UTN.cer TLS_VERIFYPEER=NONE This all still gives me the same error, no matter if I choose TLS or SSL in Evolution's server setting, no matter if I enter :143 or :993 in the hostname field. Nov 25 16:38:14 katie imaplogin: Connection, ip=[::ffff:83.248.131.164] Nov 25 16:38:14 katie imaplogin: LOGIN: DEBUG: ip=[::ffff:83.248.131.164], command=CAPABILITY Nov 25 16:38:14 katie imaplogin: LOGIN: DEBUG: ip=[::ffff:83.248.131.164], command=STARTTLS Nov 25 16:38:14 katie imaplogin: couriertls: accept: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Oops. I'm terribly sorry, but I got fooled by Evolution's "Check for supported types"-button - I never left/closed the settings window. Next time I fired up evolution it worked. (This ought to be filed as a bug by it self methinks.) What I'm saying is that the config pasted does work with "Use Secure Connection" set to "SSL encryption".
Does "Use Secure Connection" set to "SSL encryption" work for everybody?
SSL encryption works for me
you guys aren't using the "imap4" (as opposed to "imap") account-type, are you? If you are using "imap4", that would be why... I just noticed this bug in imap4 last night and think I fixed it (I committed a patch but it's untested because I don't have an evo build environment anymore... then again, no one should really be using imap4 anyway since it's not supported)
isn't this one fixed by bug 345135, where TLS was disabled by a wrong HELO sent?
So is this still an issue for anybody or can this be closed as OBSOLETE as per comments 14 and 16?
Please feel free to reopen this bug if the problem still occurs with a newer version of Evolution.