Verbindungssicherheit STARTTLS funktioniert seit TB 38.1.0 nicht mehr

Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
* Thunderbird-Version: 38.1.0
* Betriebssystem + Version: Windows 8.1 pro
* Kontenart (POP / IMAP): POP / IMAP
* Postfachanbieter (z.B. GMX): eigene Mailserver (Linux/Postfix/Courier/MySQL)
* Eingesetzte Antivirensoftware: lokal Windows Defender abgeschaltet
* Firewall (Betriebssystem-intern/Externe Software): Windows 8.1 abgeschaltet

Hallo,
seit TB 38.1.0 funktioniert die Verbindungssicherheit STARTTLS nicht mehr. Es kann keine Anmeldung mehr durchgeführt werden, sie ist unvollständig.

Auszug aus Maillog
Jul 17 17:43:33 tb imapd: Connection, ip=[::ffff:meine_ip]

Normal käme dann hier noch folgender Eintrag, aber dieser Eintrag fehlt! Da kommt dann nichts mehr
Jul 17 17:43:33 tb imapd: LOGIN, user=thomasbarth@meine_domain, ip=[::ffff:meine_ip], port=[50159], protocol=IMAP

Unter Ubuntu mit TB 31.7.0 und unter Windows mit der Vorgängerversion 38.0.1 funktioniert noch alles problemlos. Ich habe TB 38.0.1 wieder installiert und die automatische Update-Funktion deaktiviert.

Thunderbird 38.1.0 hingegen zeigt dann z.B. unten in der Statuszeile "Funktionsumfang des Mailservers abrufen...", was nicht gelingt. Beim Einrichten eines Kontos wird angezeigt, dass der Benutzername oder das Paßwort falsch sind, was auch verständlich ist, wenn der Server gar keine Abfrage erhält.

Das Mailserver Zertifikat wurde selbst erstellt und bisher immer als Ausnahmeregel bestätigt. Dieses Fenster erscheint mit 38.1.0 auch nicht mehr. Kann es sein, dass TB 38.1.0 mit selbst ausgestellten Zertifikaten nicht mehr zurecht kommt?

An wen müsste ich wenden, wenn ich sicherstellen möchte, dass die Entwickler dieses Problem erfahren?

Thomas Barth

Hiviellleicht ist das Problem ein anderes. Wenn ich ein neues Konto unter TB 38.1.0 einrichten möchte, werden ja die Servereinstellungen ermittelt, die man manuell bearbeiten kann. Und während ich Änderungen vornehme, steht in der Statuszeile von TB die ganze Zeit: Überprüfe den Funktionsumfang des Mail-Servers... Da passiert aber nichts, normalerweisewurden diese Informationen immer blitzschnell ermittelt. Und solange TB diese Informationen nicht bekommt, ist die weitereEinrichtung blockiert, da Benutzername und Paßwort immer als falsch angegeben werden. Einen Timeout bei der Abfragedes Funktionsumfanges gibt es nicht. Ein Update des Mailserver wurde heute noch vollständig durchgeführt (Debian/Jessie) und neu gestartet.

Also, sobald ich von 38.0.1 auf 38.1.0 aktualisiere, lässt sich der Funktionsumfang des Mail-Servers nicht mehr abfragen.

Hier einmal ein Test mit telnet unter Einbeziehung von openssl:

root@ubuntu14:~# openssl s_client -starttls smtp -connect mail.mydomain.de:25
CONNECTED(00000003)
depth=1 C = DE, ST = NRW, O = Private CA, OU = Administration, CN = www.mydomain.de, emailAddress = info@mydomain.de
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=DE/ST=NRW/L=Duesseldorf/O=Private/OU=Administration/CN=mail.mydomain.de/emailAddress=info@mydomain.de
   i:/C=DE/ST=NRW/O=Private CA/OU=Administration/CN=www.mydomain.de/emailAddress=info@mydomain.de
 1 s:/C=DE/ST=NRW/O=Private CA/OU=Administration/CN=www.mydomain.de/emailAddress=info@mydomain.de
   i:/C=DE/ST=NRW/O=Private CA/OU=Administration/CN=www.mydomain.de/emailAddress=info@mydomain.de
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEFDCCAvygAwIBAgIJAJ7xmuAqbP2LMA0GCSqGSIb3DQEBCwUAMIGAMQswCQYD
VQQGEwJERTEMMAoGA1UECAwDTlJXMRMwEQYDVQQKDApQcml2YXRlIENBMRcwFQYD
[...]
zbTfTpLnzxLu/x4szOpK9AeVjNDPo0h6kNcHBmIQtOmY8yH9AE2hS93p94GSU4n8
0KsW29Gv90pKp69l82wylBy1zU+IFcFvrqgrWdkUpxanlAodzme152OVpmoDJH/f
VRRmHeKa3mcg1THlHzyca/ipV6gKo2Eebs4lyMsZdQ0SoHJsSX2K6w==
-----END CERTIFICATE-----
subject=/C=DE/ST=NRW/L=Duesseldorf/O=Private/OU=Administration/CN=mail.mydomain.de/emailAddress=info@mydomain.de
issuer=/C=DE/ST=NRW/O=Private CA/OU=Administration/CN=www.mydomain.de/emailAddress=info@mydomain.de
---
No client certificate CA names sent
---
SSL handshake has read 2953 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 06508E248801EABADDF063582C1B99166BD1E0F4A12F4D3BD361E97CB753ADFA
    Session-ID-ctx: 
    Master-Key: D16B8F2ED9CE[...]3327BDF2B5
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 78 50 ec 69 de 89 a6 33-06 7e 44 3e 98 79 1b 0c   xP.i...3.~D>.y..
    [...]
    0090 - a2 97 ca 79 35 e6 9e 9f-52 89 ae 0b 97 45 f9 8a   ...y5...R....E..




    Start Time: 1437198690
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
250 DSN
EHLO test
250-mail.mydomain.de
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
QUIT
DONE

Ich bin nicht der Einzige mit dem Problem

https://bugzilla.mozilla.org/show_bug.cgi?id=1183650
https://bugzilla.mozilla.org/show_bug.cgi?id=1184488

Hallo Bagalut,
das Zertifikat wird eigentlich von TB angenommen. Ich hatte es heute morgen einmal neu erstellt und konnte es im eingeblendeten Fenster, mit dem Hinweis, dass das Zertifikat nicht vertrauenswürdig eingestuft wird, als Ausnahmeregel hinzufügen.

Entsprechend folgender Anleitung konnte ich meinen Mailserver schon einmal gegen logjam absichern.
https://www.howtoforge.com/tutorial/how-t…-logjam-attack/

# openssl dhparam -out dhparams.pem 2048
in /etc/postfix/main.cf
smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
smtpd_tls_dh1024_param_file = /etc/postfix/dhparams.pem

OpenSSL ist eigentlich recht aktuell
root@mydomain /etc/postfix # openssl version
OpenSSL 1.0.1k 8 Jan 2015

Keine Ahnung, wann OpenSSL 1.0.2 in stable gelangt, dafür gibt es noch zuviele Bugs
https://packages.qa.debian.org/o/openssl.html

Problem bleibt, dass der Funktionsumfang des Mailservers nicht ermittelt werden kann.

Ich habe in https://bugzilla.mozilla.org/show_bug.cgi?id=1183650 geschrieben, dass ich ebenfalls betroffen bin. Dieser "John Du" in dem Bug-Thread schrieb, dass er das Problem lösen konnte, indem er neuere openssl Bibliotheken installiert hatte (openssl-0.9.8e-36 -> openssl-1.0.1e-30). Bei meinem Mailserver ist aber bereits openssl-1.0.1k-3 installiert! Daran kann es dann auch nicht liegen.

Wie erhält man in Thunderbird die Informationen, die der "tilt 2015-07-16 04:21:41 PDT" im 4 Kommentar kopiert hat.

try to log in IMAP auth: server caps 0x4c3325, pref 0x1006, failed 0x0, avail caps 0x1004 (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000, LOGIN = 0x2, old-style IMAP login = 0x4, auth external IMAP login = 0x20000000, OAUTH2 = 0x800000000) trying auth method 0x1000 got new password IMAP: trying auth method 0x1000 PLAIN auth[...]

Gibt es dafür eine Konsole? Seine Ausgabe zeigt nämlich, was TB 38.1.0 beim Login anders macht als TB 38.0.1. Und das sieht wirklich nach einem TB Bug aus, das die Entwickler beseitigen müssen.

Edit: Das Verbindungsprotokoll habe ich nun in TB 38.0.1 und 38.1.0 geloggt und als Anhänge dem Bug-Thread beigefügt.

Das Protokoll wurde von Thunderbird erzeugt. Dafür kann ein Batch-Datei anlegen, die man in der Windows-Console aufruft.

Inhalt der Batch-Datei:
set NSPR_LOG_MODULES=imap:5,smtp:5
set NSPR_LOG_FILE=%USERPROFILE%\Desktop\tbconnection.log
"%ProgramFiles(x86)%\Mozilla Thunderbird\thunderbird.exe"

Quelle: https://wiki.mozilla.org/MailNews:Logging