Your message dated Sat, 28 May 2016 21:03:36 +0200
with message-id <[email protected]>
and subject line Re: Bug#819747: icedove: STARTTLS fails silently for no
apparent reason
has caused the Debian Bug report #819747,
regarding icedove: STARTTLS fails silently for no apparent reason
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
819747: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819747
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: icedove
Version: 38.7.0-1~deb8u1
Severity: normal
Tags: upstream
Dear Maintainer,
I'm running icedove for years as MUA via IMAP for my Cyrus2 mail
server. Access has been encrypted using TLS on port 143 for many
years. Recently, it suddenly ceased working. In the relevant time
frame I updated icedove and had to renew the server certificate.
I can contact the mail server using openssl s_client. And of course by
falling back to plain text access. Wireshark shows that an apparently
normal STARTTLS sequence is answered by icedove with "Bad
Certificate", immediately. However, from UI perspective icedove seems
to hang infinitely. There is no message about problems with
certificates shown to the user. This at least should be considered a
bug.
Beyond that I cannot find any actual problems with the certificates in
the chain. I am able to import both, server and CA, into icedoves
certificate store. Inspecting the details of the server certificate
correctly lists the CA certificate in the tree view. But still
connection fails the same way.
I'd expect icedove to complain about the certificates also when
importing them into the store, if there is actually an issue with
them.
Some more information can be found at
http://serverfault.com/questions/766389/thunderbird-starttls-fails-connecting-to-cyrus-imap-2-2-13
The example log using NSPR_LOG_MODULES=all:5 published there neither
revealed anything useful.
Kind regards,
- lars.
-- System Information:
Debian Release: 8.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages icedove depends on:
ii debianutils 4.4+b1
ii fontconfig 2.11.0-6.3
ii libasound2 1.0.28-1
ii libatk1.0-0 2.14.0-1
ii libc6 2.19-18+deb8u3
ii libcairo2 1.14.0-2.1
ii libdbus-1-3 1.8.20-0+deb8u1
ii libdbus-glib-1-2 0.102-1
ii libevent-2.0-5 2.0.21-stable-2
ii libffi6 3.1-2+b2
ii libfontconfig1 2.11.0-6.3
ii libfreetype6 2.5.2-3+deb8u1
ii libgcc1 1:4.9.2-10
ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u4
ii libglib2.0-0 2.42.1-1
ii libgtk2.0-0 2.24.25-3
ii libhunspell-1.3-0 1.3.3-3
ii libpango-1.0-0 1.36.8-3
ii libpangocairo-1.0-0 1.36.8-3
ii libpangoft2-1.0-0 1.36.8-3
ii libpixman-1-0 0.32.6-3
ii libsqlite3-0 3.8.7.1-1+deb8u1
ii libstartup-notification0 0.12-4
ii libstdc++6 4.9.2-10
ii libx11-6 2:1.6.2-3
ii libxcomposite1 1:0.4.4-1
ii libxdamage1 1:1.1.4-2+b1
ii libxext6 2:1.3.3-1
ii libxfixes3 1:5.0.1-2+b2
ii libxrender1 1:0.9.8-1+b1
ii libxt6 1:1.1.4-1+b1
ii psmisc 22.21-2
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages icedove recommends:
ii iceowl-extension 38.7.0-1~deb8u1
ii myspell-de-at [myspell-dictionary] 20131206-5
ii myspell-de-ch [myspell-dictionary] 20131206-5
ii myspell-de-de [myspell-dictionary] 20131206-5
ii myspell-en-us [myspell-dictionary] 1:3.3.0-4
Versions of packages icedove suggests:
ii fonts-lyx 2.1.2-2
ii libgssapi-krb5-2 1.12.1+dfsg-19+deb8u2
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 45.1.0-1
No more feedback from the reporter, closing.
Feel free to reopen with appropriate new informations.
Regards
Carsten
On Thu, Apr 28, 2016 at 10:05:43AM +0200, Carsten Schoenert wrote:
> Hello Lars,
>
> On Fri, Apr 01, 2016 at 08:24:23PM +0200, Dr. Lars Hanke wrote:
>
> > I'm running icedove for years as MUA via IMAP for my Cyrus2 mail
> > server. Access has been encrypted using TLS on port 143 for many
> > years. Recently, it suddenly ceased working. In the relevant time
> > frame I updated icedove and had to renew the server certificate.
>
> You don't show any public data of the certificate, so we are impossible
> to detect the problem in detail.
> Note also there is a old entry in the Debian Wiki for Icedove around
> such issues:
>
>
> https://wiki.debian.org/Icedove#Icedove_seems_impossible_to_send_mails_via_STARTLS_after_installation_of_libnss_3.14-1
>
> > I can contact the mail server using openssl s_client. And of course by
> > falling back to plain text access. Wireshark shows that an apparently
> > normal STARTTLS sequence is answered by icedove with "Bad
> > Certificate", immediately.
>
> That's the reason why Icedove isn't doing anything further, the question
> is why NSS is thinking the certificate is bad.
> By the way, STARTTLS isn't the best choice if you want TLS encrypted
> connections. Just switch to SSL/TLS (default 993) instead.
>
> > However, from UI perspective icedove seems
> > to hang infinitely. There is no message about problems with
> > certificates shown to the user. This at least should be considered a
> > bug.
>
> This is a upstream related thing so the bug report has to be addressed to
> the Mozilla bugtracker for this issue.
>
> > Beyond that I cannot find any actual problems with the certificates in
> > the chain. I am able to import both, server and CA, into icedoves
> > certificate store. Inspecting the details of the server certificate
> > correctly lists the CA certificate in the tree view. But still
> > connection fails the same way.
>
> At least the website https://de.ssl-tools.net/mailservers show up the MX
> for lhanke.de is using SSLv3 that is isn't secure anymore. And there is
> a hostname mismatch in the certificate chain. I assume we are talking
> about lhanke.de.
>
> On the website https://www.ssllabs.com/ssltest/index.html can more
> checks automatically done if needed.
>
> > I'd expect icedove to complain about the certificates also when
> > importing them into the store, if there is actually an issue with
> > them.
>
> Yes, I agree on that. But right after an import of a CA there maybe
> problems that can not be detected because the algo just can analyze the
> plain structure of the files. Unfortunately the whole certificate and
> encryption is a complex thing.
> I don't expect much progress on this n the upstream side, we as
> maintainer can't do much here.
>
> > The example log using NSPR_LOG_MODULES=all:5 published there neither
> > revealed anything useful.
>
> I wont believe that. :-)
> There are always some informations visible that helping to encircle the
> problems.
>
> Regards
> Carsten
--- End Message ---
