Closed Bug 1184488 Opened 9 years ago Closed 9 years ago

Thunderbird 38.1.0+38.0.1: SMTP+IMAP with STARTTLS: no remaining auth method

Categories

(MailNews Core :: Networking: IMAP, defect)

defect
Not set
major

Tracking

(thunderbird_esr38- wontfix)

RESOLVED WONTFIX
Tracking Status
thunderbird_esr38 - wontfix

People

(Reporter: bunk, Unassigned)

References

(Depends on 1 open bug, )

Details

(Keywords: regression, Whiteboard: [workaround: comment 7, 12-13, 17 - though not great security])

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20150713030204

Steps to reproduce:

Fetch mail using IMAP and send mail using SMTP.


Actual results:

Since upgrading from Thunderbird 31.6.0, authentication against our Exchange 2010 server using SMTP or IMAP does not work anymore. TB complains "The IMAP server ... does not support the selected authentication method." The IMAP/SMTP account in Thunderbird are both set to use STARTTLS+Kerberos/GSSAPI.

Some log messages obtained according to https://wiki.mozilla.org/MailNews:Logging using NSPR_LOG_MODULES=negotiateauth:5,gssapi:5,imap:5:

8088[1dad8600]: ImapThreadMainLoop entering [this=21122800]
0[2711140]: 21122800:exchange.iat.intern:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
8088[1dad8600]: 21122800:exchange.iat.intern:NA:ProcessCurrentURL: entering
8088[1dad8600]: 21122800:exchange.iat.intern:NA:ProcessCurrentURL:imap://bunk@exchange.iat.intern:143/liteselect%3E/INBOX:  = currentUrl
0[2711140]: proposed url = Junk E-Mail folder for connection  has To Wait = FALSE can run = FALSE
9864[1dad88a0]: ImapThreadMainLoop entering [this=21125000]
0[2711140]: 21125000:exchange.iat.intern:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
9864[1dad88a0]: 21125000:exchange.iat.intern:NA:ProcessCurrentURL: entering
9864[1dad88a0]: 21125000:exchange.iat.intern:NA:ProcessCurrentURL:imap://bunk@exchange.iat.intern:143/folderstatus%3E/Junk%20E-Mail:  = currentUrl
8088[1dad8600]: ReadNextLine [stream=15b8b9c0 nb=53 needmore=0]
8088[1dad8600]: 21122800:exchange.iat.intern:NA:CreateNewLineFromSocket: * OK The Microsoft Exchange IMAP4 service is ready.

9864[1dad88a0]: ReadNextLine [stream=23efa9c0 nb=53 needmore=0]
9864[1dad88a0]: 21125000:exchange.iat.intern:NA:CreateNewLineFromSocket: * OK The Microsoft Exchange IMAP4 service is ready.

8088[1dad8600]: 21122800:exchange.iat.intern:NA:SendData: 1 capability

9864[1dad88a0]: 21125000:exchange.iat.intern:NA:SendData: 1 capability

8088[1dad8600]: ReadNextLine [stream=15b8b9c0 nb=94 needmore=0]
8088[1dad8600]: 21122800:exchange.iat.intern:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4 IMAP4rev1 LOGINDISABLED STARTTLS UIDPLUS CHILDREN IDLE NAMESPACE LITERAL+

9864[1dad88a0]: ReadNextLine [stream=23efa9c0 nb=94 needmore=0]
9864[1dad88a0]: 21125000:exchange.iat.intern:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4 IMAP4rev1 LOGINDISABLED STARTTLS UIDPLUS CHILDREN IDLE NAMESPACE LITERAL+

8088[1dad8600]: ReadNextLine [stream=15b8b9c0 nb=28 needmore=0]
8088[1dad8600]: 21122800:exchange.iat.intern:NA:CreateNewLineFromSocket: 1 OK CAPABILITY completed.

9864[1dad88a0]: ReadNextLine [stream=23efa9c0 nb=28 needmore=0]
8088[1dad8600]: 21122800:exchange.iat.intern:NA:SendData: 2 STARTTLS

9864[1dad88a0]: 21125000:exchange.iat.intern:NA:CreateNewLineFromSocket: 1 OK CAPABILITY completed.

9864[1dad88a0]: 21125000:exchange.iat.intern:NA:SendData: 2 STARTTLS

8088[1dad8600]: ReadNextLine [stream=15b8b9c0 nb=33 needmore=0]
8088[1dad8600]: 21122800:exchange.iat.intern:NA:CreateNewLineFromSocket: 2 OK Begin TLS negotiation now.

8088[1dad8600]: 21122800:exchange.iat.intern:NA:SendData: 3 capability

9864[1dad88a0]: ReadNextLine [stream=23efa9c0 nb=33 needmore=0]
9864[1dad88a0]: 21125000:exchange.iat.intern:NA:CreateNewLineFromSocket: 2 OK Begin TLS negotiation now.

9864[1dad88a0]: 21125000:exchange.iat.intern:NA:SendData: 3 capability

8088[1dad8600]: ReadNextLine [stream=15b8b9c0 nb=0 needmore=1]
8088[1dad8600]: 21122800:exchange.iat.intern:NA:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 805a1ff7
9864[1dad88a0]: ReadNextLine [stream=23efa9c0 nb=0 needmore=1]
9864[1dad88a0]: 21125000:exchange.iat.intern:NA:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 805a1ff7
8088[1dad8600]: 21122800:exchange.iat.intern:NA:TellThreadToDie: close socket connection
9864[1dad88a0]: 21125000:exchange.iat.intern:NA:TellThreadToDie: close socket connection
9864[1dad88a0]: 21125000:exchange.iat.intern:NA:CreateNewLineFromSocket: (null)
8088[1dad8600]: 21122800:exchange.iat.intern:NA:CreateNewLineFromSocket: (null)
9864[1dad88a0]: try to log in
9864[1dad88a0]: IMAP auth: server caps 0x486231, pref 0x1000000, failed 0x0, avail caps 0x0
8088[1dad8600]: try to log in
8088[1dad8600]: IMAP auth: server caps 0x486231, pref 0x1000000, failed 0x0, avail caps 0x0
9864[1dad88a0]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000,
  LOGIN = 0x2, old-style IMAP login = 0x4, auth external IMAP login = 0x20000000, OAUTH2 = 0x800000000)
9864[1dad88a0]: no remaining auth method
8088[1dad8600]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000,
  LOGIN = 0x2, old-style IMAP login = 0x4, auth external IMAP login = 0x20000000, OAUTH2 = 0x800000000)
8088[1dad8600]: no remaining auth method
9864[1dad88a0]: login failed entirely
8088[1dad8600]: login failed entirely
9864[1dad88a0]: 21125000:exchange.iat.intern:NA:ProcessCurrentURL: aborting queued urls
9864[1dad88a0]: ImapThreadMainLoop leaving [this=21125000]
0[2711140]: offline imap url failed :imap://bunk@exchange.iat.intern:143/liteselect>/INBOX
8088[1dad8600]: 21122800:exchange.iat.intern:NA:ProcessCurrentURL: aborting queued urls
8088[1dad8600]: ImapThreadMainLoop leaving [this=21122800]


Expected results:

With Thunderbird 31.6.0 the logs look like this:

5008[14525bc0]: ImapThreadMainLoop entering [this=18a2f800]
0[c0f140]: 18a2f800:exchange.iat.intern:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:ProcessCurrentURL: entering
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:ProcessCurrentURL:imap://bunk@exchange.iat.intern:143/select%3E/INBOX:  = currentUrl
0[c0f140]: proposed url = Junk E-Mail folder for connection  has To Wait = FALSE can run = FALSE
15568[14525d10]: ImapThreadMainLoop entering [this=19f25000]
0[c0f140]: 19f25000:exchange.iat.intern:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
15568[14525d10]: 19f25000:exchange.iat.intern:NA:ProcessCurrentURL: entering
15568[14525d10]: 19f25000:exchange.iat.intern:NA:ProcessCurrentURL:imap://bunk@exchange.iat.intern:143/folderstatus%3E/Junk%20E-Mail:  = currentUrl
5008[14525bc0]: ReadNextLine [stream=189ea928 nb=53 needmore=0]
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:CreateNewLineFromSocket: * OK The Microsoft Exchange IMAP4 service is ready.

15568[14525d10]: ReadNextLine [stream=189eab08 nb=53 needmore=0]
15568[14525d10]: 19f25000:exchange.iat.intern:NA:CreateNewLineFromSocket: * OK The Microsoft Exchange IMAP4 service is ready.

5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:SendData: 1 capability

15568[14525d10]: 19f25000:exchange.iat.intern:NA:SendData: 1 capability

5008[14525bc0]: ReadNextLine [stream=189ea928 nb=94 needmore=0]
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4 IMAP4rev1 LOGINDISABLED STARTTLS UIDPLUS CHILDREN IDLE NAMESPACE LITERAL+

15568[14525d10]: ReadNextLine [stream=189eab08 nb=94 needmore=0]
15568[14525d10]: 19f25000:exchange.iat.intern:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4 IMAP4rev1 LOGINDISABLED STARTTLS UIDPLUS CHILDREN IDLE NAMESPACE LITERAL+

5008[14525bc0]: ReadNextLine [stream=189ea928 nb=28 needmore=0]
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:CreateNewLineFromSocket: 1 OK CAPABILITY completed.

5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:SendData: 2 STARTTLS

15568[14525d10]: ReadNextLine [stream=189eab08 nb=28 needmore=0]
15568[14525d10]: 19f25000:exchange.iat.intern:NA:CreateNewLineFromSocket: 1 OK CAPABILITY completed.

15568[14525d10]: 19f25000:exchange.iat.intern:NA:SendData: 2 STARTTLS

5008[14525bc0]: ReadNextLine [stream=189ea928 nb=33 needmore=0]
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:CreateNewLineFromSocket: 2 OK Begin TLS negotiation now.

5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:SendData: 3 capability

15568[14525d10]: ReadNextLine [stream=189eab08 nb=33 needmore=0]
15568[14525d10]: 19f25000:exchange.iat.intern:NA:CreateNewLineFromSocket: 2 OK Begin TLS negotiation now.

15568[14525d10]: 19f25000:exchange.iat.intern:NA:SendData: 3 capability

5008[14525bc0]: ReadNextLine [stream=189ea928 nb=104 needmore=0]
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4 IMAP4rev1 AUTH=NTLM AUTH=GSSAPI AUTH=PLAIN UIDPLUS CHILDREN IDLE NAMESPACE LITERAL+

5008[14525bc0]: ReadNextLine [stream=189ea928 nb=28 needmore=0]
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:CreateNewLineFromSocket: 3 OK CAPABILITY completed.

5008[14525bc0]: try to log in
5008[14525bc0]: IMAP auth: server caps 0x1587235, pref 0x0, failed 0x1000000, avail caps 0x0
5008[14525bc0]: (GSSAPI = 0x1000000, CRAM = 0x0, NTLM = 0x20000, MSN =  0x0, PLAIN = 0x100000, LOGIN = 0x0, old-style IMAP login = 0x200000)auth external IMAP login = 0x0
5008[14525bc0]: trying auth method 0x1000000
15568[14525d10]: ReadNextLine [stream=189eab08 nb=104 needmore=0]
15568[14525d10]: 19f25000:exchange.iat.intern:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4 IMAP4rev1 AUTH=NTLM AUTH=GSSAPI AUTH=PLAIN UIDPLUS CHILDREN IDLE NAMESPACE LITERAL+

5008[14525bc0]: IMAP: trying auth method 0x1000000
5008[14525bc0]: MD5 auth
15568[14525d10]: ReadNextLine [stream=189eab08 nb=28 needmore=0]
15568[14525d10]: 19f25000:exchange.iat.intern:NA:CreateNewLineFromSocket: 3 OK CAPABILITY completed.

5008[14525bc0]:   nsAuthSSPI::Init
5008[14525bc0]:   InitSSPI
15568[14525d10]: try to log in
15568[14525d10]: IMAP auth: server caps 0x1587235, pref 0x0, failed 0x1000000, avail caps 0x0
15568[14525d10]: (GSSAPI = 0x1000000, CRAM = 0x0, NTLM = 0x20000, MSN =  0x0, PLAIN = 0x100000, LOGIN = 0x0, old-style IMAP login = 0x200000)auth external IMAP login = 0x0
15568[14525d10]: trying auth method 0x1000000
15568[14525d10]: IMAP: trying auth method 0x1000000
15568[14525d10]: MD5 auth
15568[14525d10]:   nsAuthSSPI::Init
15568[14525d10]:   InitSSPI
5008[14525bc0]: Using SPN of [imap/iatvexch01.iat.intern]
15568[14525d10]: Using SPN of [imap/iatvexch01.iat.intern]
5008[14525bc0]: AcquireCredentialsHandle() succeeded.
15568[14525d10]: AcquireCredentialsHandle() succeeded.
15568[14525d10]: entering nsAuthSSPI::GetNextToken()
5008[14525bc0]: entering nsAuthSSPI::GetNextToken()
5008[14525bc0]: InitializeSecurityContext: continue.
15568[14525d10]: InitializeSecurityContext: continue.
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:SendData: 4 authenticate GSSAPI

15568[14525d10]: 19f25000:exchange.iat.intern:NA:SendData: 4 authenticate GSSAPI

5008[14525bc0]: ReadNextLine [stream=189ea928 nb=3 needmore=0]
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:CreateNewLineFromSocket: +

5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:SendData: YIIUAgYJKoZIhvcSAQICAQBughPxMIIT7aADAgEFoQMCAQ6iBwMFACAAAACjghKEYYISgDCCEnygAwIBBaEMGwpJQVQuSU5URVJOoigwJqADAgECoR8wHRsEaW1hcBsVaWF0dmV4Y2gwMS5pYXQuaW50ZXJuo4ISOzCCEjegAwIBEqEDAgE3ooISKQSCEiUuI6WmarGFPSu41iMawKA57i0be7rym9i0Qo+Msig13UXsoVu7pa+ODZ5bR0zlt5B/QJ6YHUZOCed+6wXpKKuMMycv0dEOY6rhVeTGfi9+6+YF3dvuazEQ1nwtJX2MVVfDPihCzmPI2/p23595EcDCnxt6MiIUOPZ1tpWg6xaz/6euyok9fsoi4Y8MmRDLAITLCn3mrymjULNO5HJv
5008[14525bc0]: IAu2i7m8b88k78AJhChbjl9QkoViEjUV58P8gURebrk4atS9jPiKRf/tXckm8+AUbQGli0KvEQnQwWHHDAbrerG1l+EiJaRsvpTu9wquB1BrTscPDHGB720L/6b/45xPmtQgI06y9w2o51AiVwQevgviebUPlcyt0Fgdawr6UgM0vOx/DUbua+QwhA7XDrX7182Fwuv1/whjrzHCXEsAnXtFEjhzq+gB7I0xl2fsnwB+t8s6TUeriGahZ7B4x/9Rk2FlKlqC7LJuIcUgIYy6/6M0Ma63z29ubzXSBjX9Ph7F81fOmEhp8bMUj4+tXoVO3MhLvmpqFsufEGeELDsypgbG8UpLBKYlNtwfHzgHXYYs8EJ0az96VtsIdN2TpccOmgYA5/RkZsoxOAPD
5008[14525bc0]: UnVjNnCSfYr7t6NZxyclTxZcMEUCuXjwj8A9jE/1vWo76ywiGqukILSyglh+jLjcdUBaHrWNMlAiBLn1iKqXynixUUVEDHaQKO+tIjWqqSnaBDzPWfYK8cQjgYdXjW1AL9AShyK03JR+WPPST/iR0ngOJhZBzS813bT5NwVUVJVdNnfj6lA6wRXGAnOLfJhNwZV5qzBx+BWx1uVeLa5qG2f8Oj6yO6nAATWxVqXfoE8h7WiofQG2R2VZj8MA02OjCWjL+4hPEgmJZhh1vldS9UwLWONTF2qa+YoFC21zqGLrvrgHrgqG2IKrHsPfOZHMxGlcmQqiagdREZ5VWsn8QbT0KYbVTqCH6HNpgsPBRNClJvYRzds2xeKBSHkaU7ChfYqfyigpAvKSGn2i
5008[14525bc0]: f1VhpcIIz/HYjxeaRRzqS5deJ/b3huk8wt8Vw2ZD62tDm8z6A84HpsWIjNJQOJbrpE/bEqOAVpFrfXmuVHwx7IbqeiblsuSzDXETP2fozJ7SgQ8EUKVaDL5hVwmdax+s/vX753/mD20G/tIR34lnShF8AASaikxSer0Am3vixAS3fVPhv/rQRKig7B/FidHLc5XvKdSqGblbv8A/NSJBV/2YohbYAZusEIWI08cbKpLHfnM4AyB4DAzqlOiQHmUM4wSZvRddg0/iJ0EmLQCuma6UZ/4jf0r2Wp3IoYXgsuxtaJXaC1LCAIu4NGlVRI/I1QI3NotynXiYjXLTOn5nhHbsS1FJUXAesqPdEQnWFzcopUC+A+fF7JDYg9Sdu5P17je6i6L46lWFMbBk
5008[14525bc0]: QMffCu/IhsoUAT2qO/PSZ5yzufiibAUcEavWFK/kdg5bEIV3CjO1c4FEDTUIZNuAqHrYLmxgkj8AOHW0anqRJfmCZMcX8th3FZB0P9vtZrOX8+bLcL+pSeKdb2/ZGKpH+fV4ArG9M1BlmAAr1brXc6aW3GqIHFU8z2mK++F/Ap96f9Aqk0GNP6OsIdsJzYksB7u+oO1vGP8Q4t9lCvtMGk67V2ONe0iK/ULfZPPJpUf96u9HqcZIlqtkDKPGlg5VEnqFqIlRihjkDtDWktqa9K3vbies1B8SqGeN7xoVKUnsSvxfpmEitbrrWsgNBWLpmYnvU2YM0tlXwTKzHZDi7ISsIQmNjnzYnpEjpPisJcz5OxpU5QvOlhbHl+bxfzECPDIcC5/h9ciwkye5
5008[14525bc0]: 6UhziYSTsjzRRrQjccXEflI/FlTFVmFSr//vRq+JsgrDNSY6kHfN/jr5i6pCFdbFd02i/iL0HedOW2LS/P9O5NRZsIC3LzG9XaZLbMwSxYiclUAMgQeFwPs89gHN7uUONZY2dXL4QeObWZkay7dVt42GUU/J/lorcTsaWvseGYEbTCCUVL4T/BAmaPmeaBV5WvjD8lU0yfi249gRMb5owG4WnMP4NC2zfIzuwMgu1+uR1pRoNcsMBcjKZeld3H6GO9AUOPwfEygmLU7H2NCvOx28MmzoQ1Y5JCY8GZIofprV92FRSuRSVUeuWgFBuFE7kjsbWg33ZLrHRTlF+C49GNAZUypfLtKby2lQ3HM/Y+Z+qvIwDQ+CsL0FeO43pW6R6FdDoAgvCB8kChFT
5008[14525bc0]: pXnEGO591jdeGquyCYMqCPefwd5A7K929GFv/nLQEQ6qHyH9VcF8YcJbE+4XE7Y5Q45U0qbBs2UV73QdmyVbx4UeLx3NRfp2WoeP5Rgv1f9S+hxZA3jpzQNlrWb8HzG6AkOgfmdU5zDyCu+YCAHL5D3P/8Ne5dhP2E3EI3V3NSU4XdhwGxNIg73r1PY/ucu5Ww5Mnyeuqe7m/LMArQkGOGQ2IWlrinB+feWsvLyL6Cv4cHIakSgICcShLvYyBynKD2ov6mOe6W393R0mpzId/ri5vNwf9VNHe+CQKaHRTBCgi4VVuaKSgPpAkkQEbaXWSdi9OSD0MVUHiynPo+zeLlcP0DoRvweV5NCi5/hcARKvEMV6ovZ3sWc7bQ+m23kxj8DhZzACD/RiYxby
5008[14525bc0]: 4kr6rIQ5aW3qFw3xgzd9+4VYrYJgWliwF5Txn22K2p4KOh7KJrHQ+HXe2otF4mjPuonBmIinLYHkF1SPeO2W5pmlzo3sKKlCubeTXHn1WUCXI/LQjcH+PB/kbMbPl2PmGlwIH8UDQ/Y5lhKOVmzx6wukCE9PB85W14MWYfKG6dvuakoqBBeFH9xouACx0iEKKsaJC/oOCZYy2dRzq50PC9RDWOalau8q4QHXZBOA5wHL+USDhVhctmMims6BF6aaawdgRMNnBsSFgS8rHa2O9Ui3aqfvhnnDBiXgGxZjlPAxfUp+LnG3KX5Y/KrEOS1LJVisNdM309JBQ53HRADMBUtYzEtjpL+hgPgkheeNMWicF0jMj4uDCjVl155mS9D/0ybGPn7KP+Di3wu6
5008[14525bc0]: lwo0i+97C0eFseteFV+yiN74BkqyB/ljdg17r0Ydl2GAMreCrETWn50CrAdDg7DszPxRxW1ZWSnmnUXTr689B5WIk58rEQUmRuT6aOtj1lfP3ALtaqS/l75G/GRim1TEvLgitwGc8AZ6GFcHy6qVApt+6Xr8AfRVuPDwC8g/yA6Y4RzdpKQPLODTnf3h/GA0kB1izaHIj2ItFYXoy4ogzOYi1LY5D8C2BBZie2qtrjNIoDsel93vCArczwMQRnvtinKppi0GQoVBzZeO9W7xXIq9azY657FFGRlyRg1HMLoeoY+z9G3O+pVROz7VSeH5Ao8X8cNlfnlW9GqfSTyEFk3eaQerw5iQLaDMjKtkakemWlvTE/Gx2rr4fov5mCZXJ5AW7V/C4NHcx+ob
5008[14525bc0]: jOKLENArwiLUkCxfxLu+FMtiMe7LnIDP+T52IDwgG5OY+iUikR/eJax3qBCV2osprk+Rw2Jve0AXuq41Dvi5NWaLo2juEKB15P02KS5lcZ07PU6MdJmaAHMyV83F6FEI5GX2foAi9iUfXACeefrL+MODtEjbvtm2jiZdjRr+tFwo8jzMTd/pYklQBBYwnSOuS94sFi5MHACuDAjY9HcX2rfsi0H66xGSq1brX91D9i9D5Y9NiRdVUm2hT1QXm1ydjZR2MnZvtdif9X3XuOFPJ7JN2I4FRzKdHklcI4e+IFEftn1keXgIBANIiS3vmLMKr5phHkn7jdm8NSOyFUF6fynj7SZACxrH1H2JgL0fM7M5nzFQEeScR4mEq1dwuUtIvSiE0dEogenrRhtO
5008[14525bc0]: iPpS+sltM9wrJsQwtNIh7VWThLileFFhOypZLaTEnbtYLcno6HrMzTS4jGMInTlnC4NZLO8619kXcWWwDD0XYa6/jr6OTcQUjX4BSWGhwRMAyp/T8bHlLSTKgv/BgM48XhI+DEl9B6t4y7kuU84RT7H5FVNesh5aXnLoclOJRL4pnKR1PPLqo2vyNvRNbu4KMpWcSBskBfUArWxoX3/Z65eK6pszMNkJreNctyDfkM6Ssvc/8k7jxoQsUVLwexlxOe0UD6i0viqyunMrDmDeDq1yansekaXvLL5fIyjBvEMZwRtKo3RFev8Eqn0DXuVCzwyuX4fyUqSRQLR3Eu1EC6STXqserxnfbrhBl5Im9n89nzXlFKDk5huBOwVSQbUFvgxq9iSuQ6lLvulW
5008[14525bc0]: 9TOuRHaJJrwkXe/Fkhs0EhANIeSATzNTGkrnwrDQpfSlS9PU1j1FT8C2ILRRozvwzY896nhBQZgDg9B0MrmJVdne1QbH9TsqTIYJoButnbOY63Fh8MK5ep/sCGNqciiaOWQ+n9bhBvHRBfpyR65MMdyF2IpUTmZxrbBb5IMt3GmT1KvIPOh3vzvP4jcRNNC0FtTGmDiJiNIeeiZMR0G9X16Zvth1AbtLY7jlWHlzcuoCeJ5zVaEZyagKy+DLiR04dFzD1O0Li5QNq+di0y8pLiXfmq/L3C2nu7XScDJALrLfop8uhqE8yRChSKvoVp1JKVLaCkoSU0iIKG3FE9HP1Nv59aHWQ/tayf8gsL5tzh8MGpAKKl3BniFc32vpat7WbcpQOKKul3WXI2ta
5008[14525bc0]: da6lLRwea+ZenPFN7Is/d+mxJpu2LyTdjcMMnYlVLWAlqp1kaAeU3M81A8OiK6HdiD3OYZM+5kHlMP0qO4ZM4km+NCFo0pgtAo/RmEg8HIp135jVMp4WK39nOXB0AoBhGdEPWFhF7o4JOhFSxIHQaN5ZxAjOSjQ7tGlwrHTTUF8VtCMhZPsFgYuZhtNhWzIIcCAh6Ihcf3rM0LNDgu9Bc20tdkIJpqqh2Gt6GZ3xARs54784iIVX5f1VGp6ad6xGcnat2whuNePSJNnWz5I+wf1vTR5rxbRvNvXMXNdepnBxjpxuaXWNvGZwZmPW3AnALUB/9O5X2NO6+7Bxlduh2Ir5PJCAugrAM7H9BmJO/CDycJXag7EfInO7oTlfajdW0qmVabXTDZ6JurfK
5008[14525bc0]: uDM4ijpnOm5Y1Jr3ULedb9ege74K8U/f9+wOzSlD9luV6omzKdNFS5KbW50WEKrRcATH2uD06AiQa6dCOujNIi5mCdXOljuHTm2gn2WaXIhOlhvflwcgiKuuG64GvmVM1kwhNbmQbXAeFXuztL3rvWusRoi9TBIKDs+BJznSyyo7voIEIdRmy9zj7UN0yWxBHo0bmTXXjiHyKIdnOJZTR/1Y4LK1dMFRs9Je9w5QpU0h1sDhMfa3gsmO2feLVkY+IM9kuLrsjJvCFuqq5kQZ7GVpDUO7Iud4X49AoAzOxGuKTYOJSkghzqGg9P1Py22xUluFpY4L28zfgOyATKMSxHmJZFTYvvlqwheIK2iJ99dYQ5/uTyT9uf7XIY2isqdQIZzh2LN6Hl7oPiN4
5008[14525bc0]: 45m4/AaESgXQLxFwEw97QADCv1P0r6mxGVAlTRMhbXNHOjIgULuafz91VQq2HPqxzvqAiGrssCraHo4nnyBriucZJSYzgTg4q89zU7y0FrpGoFhJNqm4jWNDJfb1Z94D6OASUTb3+UJKf2QVciK821T79VTIRZ66dzzAva8ytf996SBzJ2IuDSEYYrY196NuNewa0Q9GqYkII9JIUoQAdoksgT/WR+QACJKiuuPGDjxW4TiYmKETzbIcaGcRxWQvcAoqOiDLstnOZG32EAVXjcVjVDY7ZYc0r3a0rM6CD4HVDUDpAhDf5THCxh1Mrq9sUYcRvK/J650RR4V865PrHyldK5uvWRUD8Ay8atnfqpWY8d0bYeFFAL0lcDes3D4Qu1stZpJ41aXiYmA/
5008[14525bc0]: i5DizhIwaz4Jl+I1Q0o1jOcGb+0pL3Fm9oWZndKB7MrGDbnZ4XL9ZDOrzjonbS7geRb87GjOplhseF5xfWGyJJ+Gpk5KGgpu9TbCuP+ShNklkdnCt90DaEjHhm5FKGnRgWqLdyzQA9Yk1ofiprWzJ5jT8wx0NkrOoQnPokGDwmNQuG8uZVUy4/DwCDHRYUWrgbt5ZXJqzL7EqMYKYy2j9h7wslu1WJgqw0SU0fabEPsx+WAA1dyCpfp/fp57itrWvMESqWr7fdWb9sul91la9RTW2lj5IdrRozYXg3IvLW59JKP7Rf72Yl0O6npPzRcIO0fDqK8uStdOF2pCYl9XjXCPjp015I/Wh+pVcRsFYqTW6EyvR2ntconeFjhpczBHpIIBTjCCAUqgAwIB
5008[14525bc0]: EqKCAUEEggE9G1zzdcSIRXPTWdzVfl+Ogo4Y9XT1SNKESjt+JOH9pDMYtKvFMYhAMHJGB6TqVEDG4T++PY9XhyWT7MmMFGdndqU+Lv8KzVAza2d6dzeJ51blEN1ed7pS7GzZD+ipmzTcODBjCnlQY77ZDJ6gau1eCMaC2tzR5vvnT/B5JxjvoVaU9Ob0af2CZ6wck6qn5g2gY8aSg39iRLozH6P+BHec6mxp+y3CnorBCG7+cKNW6hq8D4fTM09OKRL4weImsyDi3xRT7Tw2rP7kgdte5cyeW5I8uGISybKeBzKexy9XQt4hlqXZTJt+UwAR8ihW+7vZ/XGfsHjMEur4jLIxIkTl+SZgC0ue2zEk9//CFyb/0ZYBC9jd9dy1fvfOxJ4TGemKb1ai
5008[14525bc0]: ckPlp4p+uVaqTaqewq7fdimnvY/phbo81Ys=

15568[14525d10]: ReadNextLine [stream=189eab08 nb=3 needmore=0]
15568[14525d10]: 19f25000:exchange.iat.intern:NA:CreateNewLineFromSocket: +

15568[14525d10]: 19f25000:exchange.iat.intern:NA:SendData: YIIUAgYJKoZIhvcSAQICAQBughPxMIIT7aADAgEFoQMCAQ6iBwMFACAAAACjghKEYYISgDCCEnygAwIBBaEMGwpJQVQuSU5URVJOoigwJqADAgECoR8wHRsEaW1hcBsVaWF0dmV4Y2gwMS5pYXQuaW50ZXJuo4ISOzCCEjegAwIBEqEDAgE3ooISKQSCEiUuI6WmarGFPSu41iMawKA57i0be7rym9i0Qo+Msig13UXsoVu7pa+ODZ5bR0zlt5B/QJ6YHUZOCed+6wXpKKuMMycv0dEOY6rhVeTGfi9+6+YF3dvuazEQ1nwtJX2MVVfDPihCzmPI2/p23595EcDCnxt6MiIUOPZ1tpWg6xaz/6euyok9fsoi4Y8MmRDLAITLCn3mrymjULNO5HJv
15568[14525d10]: IAu2i7m8b88k78AJhChbjl9QkoViEjUV58P8gURebrk4atS9jPiKRf/tXckm8+AUbQGli0KvEQnQwWHHDAbrerG1l+EiJaRsvpTu9wquB1BrTscPDHGB720L/6b/45xPmtQgI06y9w2o51AiVwQevgviebUPlcyt0Fgdawr6UgM0vOx/DUbua+QwhA7XDrX7182Fwuv1/whjrzHCXEsAnXtFEjhzq+gB7I0xl2fsnwB+t8s6TUeriGahZ7B4x/9Rk2FlKlqC7LJuIcUgIYy6/6M0Ma63z29ubzXSBjX9Ph7F81fOmEhp8bMUj4+tXoVO3MhLvmpqFsufEGeELDsypgbG8UpLBKYlNtwfHzgHXYYs8EJ0az96VtsIdN2TpccOmgYA5/RkZsoxOAPD
15568[14525d10]: UnVjNnCSfYr7t6NZxyclTxZcMEUCuXjwj8A9jE/1vWo76ywiGqukILSyglh+jLjcdUBaHrWNMlAiBLn1iKqXynixUUVEDHaQKO+tIjWqqSnaBDzPWfYK8cQjgYdXjW1AL9AShyK03JR+WPPST/iR0ngOJhZBzS813bT5NwVUVJVdNnfj6lA6wRXGAnOLfJhNwZV5qzBx+BWx1uVeLa5qG2f8Oj6yO6nAATWxVqXfoE8h7WiofQG2R2VZj8MA02OjCWjL+4hPEgmJZhh1vldS9UwLWONTF2qa+YoFC21zqGLrvrgHrgqG2IKrHsPfOZHMxGlcmQqiagdREZ5VWsn8QbT0KYbVTqCH6HNpgsPBRNClJvYRzds2xeKBSHkaU7ChfYqfyigpAvKSGn2i
15568[14525d10]: f1VhpcIIz/HYjxeaRRzqS5deJ/b3huk8wt8Vw2ZD62tDm8z6A84HpsWIjNJQOJbrpE/bEqOAVpFrfXmuVHwx7IbqeiblsuSzDXETP2fozJ7SgQ8EUKVaDL5hVwmdax+s/vX753/mD20G/tIR34lnShF8AASaikxSer0Am3vixAS3fVPhv/rQRKig7B/FidHLc5XvKdSqGblbv8A/NSJBV/2YohbYAZusEIWI08cbKpLHfnM4AyB4DAzqlOiQHmUM4wSZvRddg0/iJ0EmLQCuma6UZ/4jf0r2Wp3IoYXgsuxtaJXaC1LCAIu4NGlVRI/I1QI3NotynXiYjXLTOn5nhHbsS1FJUXAesqPdEQnWFzcopUC+A+fF7JDYg9Sdu5P17je6i6L46lWFMbBk
15568[14525d10]: QMffCu/IhsoUAT2qO/PSZ5yzufiibAUcEavWFK/kdg5bEIV3CjO1c4FEDTUIZNuAqHrYLmxgkj8AOHW0anqRJfmCZMcX8th3FZB0P9vtZrOX8+bLcL+pSeKdb2/ZGKpH+fV4ArG9M1BlmAAr1brXc6aW3GqIHFU8z2mK++F/Ap96f9Aqk0GNP6OsIdsJzYksB7u+oO1vGP8Q4t9lCvtMGk67V2ONe0iK/ULfZPPJpUf96u9HqcZIlqtkDKPGlg5VEnqFqIlRihjkDtDWktqa9K3vbies1B8SqGeN7xoVKUnsSvxfpmEitbrrWsgNBWLpmYnvU2YM0tlXwTKzHZDi7ISsIQmNjnzYnpEjpPisJcz5OxpU5QvOlhbHl+bxfzECPDIcC5/h9ciwkye5
15568[14525d10]: 6UhziYSTsjzRRrQjccXEflI/FlTFVmFSr//vRq+JsgrDNSY6kHfN/jr5i6pCFdbFd02i/iL0HedOW2LS/P9O5NRZsIC3LzG9XaZLbMwSxYiclUAMgQeFwPs89gHN7uUONZY2dXL4QeObWZkay7dVt42GUU/J/lorcTsaWvseGYEbTCCUVL4T/BAmaPmeaBV5WvjD8lU0yfi249gRMb5owG4WnMP4NC2zfIzuwMgu1+uR1pRoNcsMBcjKZeld3H6GO9AUOPwfEygmLU7H2NCvOx28MmzoQ1Y5JCY8GZIofprV92FRSuRSVUeuWgFBuFE7kjsbWg33ZLrHRTlF+C49GNAZUypfLtKby2lQ3HM/Y+Z+qvIwDQ+CsL0FeO43pW6R6FdDoAgvCB8kChFT
15568[14525d10]: pXnEGO591jdeGquyCYMqCPefwd5A7K929GFv/nLQEQ6qHyH9VcF8YcJbE+4XE7Y5Q45U0qbBs2UV73QdmyVbx4UeLx3NRfp2WoeP5Rgv1f9S+hxZA3jpzQNlrWb8HzG6AkOgfmdU5zDyCu+YCAHL5D3P/8Ne5dhP2E3EI3V3NSU4XdhwGxNIg73r1PY/ucu5Ww5Mnyeuqe7m/LMArQkGOGQ2IWlrinB+feWsvLyL6Cv4cHIakSgICcShLvYyBynKD2ov6mOe6W393R0mpzId/ri5vNwf9VNHe+CQKaHRTBCgi4VVuaKSgPpAkkQEbaXWSdi9OSD0MVUHiynPo+zeLlcP0DoRvweV5NCi5/hcARKvEMV6ovZ3sWc7bQ+m23kxj8DhZzACD/RiYxby
15568[14525d10]: 4kr6rIQ5aW3qFw3xgzd9+4VYrYJgWliwF5Txn22K2p4KOh7KJrHQ+HXe2otF4mjPuonBmIinLYHkF1SPeO2W5pmlzo3sKKlCubeTXHn1WUCXI/LQjcH+PB/kbMbPl2PmGlwIH8UDQ/Y5lhKOVmzx6wukCE9PB85W14MWYfKG6dvuakoqBBeFH9xouACx0iEKKsaJC/oOCZYy2dRzq50PC9RDWOalau8q4QHXZBOA5wHL+USDhVhctmMims6BF6aaawdgRMNnBsSFgS8rHa2O9Ui3aqfvhnnDBiXgGxZjlPAxfUp+LnG3KX5Y/KrEOS1LJVisNdM309JBQ53HRADMBUtYzEtjpL+hgPgkheeNMWicF0jMj4uDCjVl155mS9D/0ybGPn7KP+Di3wu6
15568[14525d10]: lwo0i+97C0eFseteFV+yiN74BkqyB/ljdg17r0Ydl2GAMreCrETWn50CrAdDg7DszPxRxW1ZWSnmnUXTr689B5WIk58rEQUmRuT6aOtj1lfP3ALtaqS/l75G/GRim1TEvLgitwGc8AZ6GFcHy6qVApt+6Xr8AfRVuPDwC8g/yA6Y4RzdpKQPLODTnf3h/GA0kB1izaHIj2ItFYXoy4ogzOYi1LY5D8C2BBZie2qtrjNIoDsel93vCArczwMQRnvtinKppi0GQoVBzZeO9W7xXIq9azY657FFGRlyRg1HMLoeoY+z9G3O+pVROz7VSeH5Ao8X8cNlfnlW9GqfSTyEFk3eaQerw5iQLaDMjKtkakemWlvTE/Gx2rr4fov5mCZXJ5AW7V/C4NHcx+ob
15568[14525d10]: jOKLENArwiLUkCxfxLu+FMtiMe7LnIDP+T52IDwgG5OY+iUikR/eJax3qBCV2osprk+Rw2Jve0AXuq41Dvi5NWaLo2juEKB15P02KS5lcZ07PU6MdJmaAHMyV83F6FEI5GX2foAi9iUfXACeefrL+MODtEjbvtm2jiZdjRr+tFwo8jzMTd/pYklQBBYwnSOuS94sFi5MHACuDAjY9HcX2rfsi0H66xGSq1brX91D9i9D5Y9NiRdVUm2hT1QXm1ydjZR2MnZvtdif9X3XuOFPJ7JN2I4FRzKdHklcI4e+IFEftn1keXgIBANIiS3vmLMKr5phHkn7jdm8NSOyFUF6fynj7SZACxrH1H2JgL0fM7M5nzFQEeScR4mEq1dwuUtIvSiE0dEogenrRhtO
15568[14525d10]: iPpS+sltM9wrJsQwtNIh7VWThLileFFhOypZLaTEnbtYLcno6HrMzTS4jGMInTlnC4NZLO8619kXcWWwDD0XYa6/jr6OTcQUjX4BSWGhwRMAyp/T8bHlLSTKgv/BgM48XhI+DEl9B6t4y7kuU84RT7H5FVNesh5aXnLoclOJRL4pnKR1PPLqo2vyNvRNbu4KMpWcSBskBfUArWxoX3/Z65eK6pszMNkJreNctyDfkM6Ssvc/8k7jxoQsUVLwexlxOe0UD6i0viqyunMrDmDeDq1yansekaXvLL5fIyjBvEMZwRtKo3RFev8Eqn0DXuVCzwyuX4fyUqSRQLR3Eu1EC6STXqserxnfbrhBl5Im9n89nzXlFKDk5huBOwVSQbUFvgxq9iSuQ6lLvulW
15568[14525d10]: 9TOuRHaJJrwkXe/Fkhs0EhANIeSATzNTGkrnwrDQpfSlS9PU1j1FT8C2ILRRozvwzY896nhBQZgDg9B0MrmJVdne1QbH9TsqTIYJoButnbOY63Fh8MK5ep/sCGNqciiaOWQ+n9bhBvHRBfpyR65MMdyF2IpUTmZxrbBb5IMt3GmT1KvIPOh3vzvP4jcRNNC0FtTGmDiJiNIeeiZMR0G9X16Zvth1AbtLY7jlWHlzcuoCeJ5zVaEZyagKy+DLiR04dFzD1O0Li5QNq+di0y8pLiXfmq/L3C2nu7XScDJALrLfop8uhqE8yRChSKvoVp1JKVLaCkoSU0iIKG3FE9HP1Nv59aHWQ/tayf8gsL5tzh8MGpAKKl3BniFc32vpat7WbcpQOKKul3WXI2ta
15568[14525d10]: da6lLRwea+ZenPFN7Is/d+mxJpu2LyTdjcMMnYlVLWAlqp1kaAeU3M81A8OiK6HdiD3OYZM+5kHlMP0qO4ZM4km+NCFo0pgtAo/RmEg8HIp135jVMp4WK39nOXB0AoBhGdEPWFhF7o4JOhFSxIHQaN5ZxAjOSjQ7tGlwrHTTUF8VtCMhZPsFgYuZhtNhWzIIcCAh6Ihcf3rM0LNDgu9Bc20tdkIJpqqh2Gt6GZ3xARs54784iIVX5f1VGp6ad6xGcnat2whuNePSJNnWz5I+wf1vTR5rxbRvNvXMXNdepnBxjpxuaXWNvGZwZmPW3AnALUB/9O5X2NO6+7Bxlduh2Ir5PJCAugrAM7H9BmJO/CDycJXag7EfInO7oTlfajdW0qmVabXTDZ6JurfK
15568[14525d10]: uDM4ijpnOm5Y1Jr3ULedb9ege74K8U/f9+wOzSlD9luV6omzKdNFS5KbW50WEKrRcATH2uD06AiQa6dCOujNIi5mCdXOljuHTm2gn2WaXIhOlhvflwcgiKuuG64GvmVM1kwhNbmQbXAeFXuztL3rvWusRoi9TBIKDs+BJznSyyo7voIEIdRmy9zj7UN0yWxBHo0bmTXXjiHyKIdnOJZTR/1Y4LK1dMFRs9Je9w5QpU0h1sDhMfa3gsmO2feLVkY+IM9kuLrsjJvCFuqq5kQZ7GVpDUO7Iud4X49AoAzOxGuKTYOJSkghzqGg9P1Py22xUluFpY4L28zfgOyATKMSxHmJZFTYvvlqwheIK2iJ99dYQ5/uTyT9uf7XIY2isqdQIZzh2LN6Hl7oPiN4
15568[14525d10]: 45m4/AaESgXQLxFwEw97QADCv1P0r6mxGVAlTRMhbXNHOjIgULuafz91VQq2HPqxzvqAiGrssCraHo4nnyBriucZJSYzgTg4q89zU7y0FrpGoFhJNqm4jWNDJfb1Z94D6OASUTb3+UJKf2QVciK821T79VTIRZ66dzzAva8ytf996SBzJ2IuDSEYYrY196NuNewa0Q9GqYkII9JIUoQAdoksgT/WR+QACJKiuuPGDjxW4TiYmKETzbIcaGcRxWQvcAoqOiDLstnOZG32EAVXjcVjVDY7ZYc0r3a0rM6CD4HVDUDpAhDf5THCxh1Mrq9sUYcRvK/J650RR4V865PrHyldK5uvWRUD8Ay8atnfqpWY8d0bYeFFAL0lcDes3D4Qu1stZpJ41aXiYmA/
15568[14525d10]: i5DizhIwaz4Jl+I1Q0o1jOcGb+0pL3Fm9oWZndKB7MrGDbnZ4XL9ZDOrzjonbS7geRb87GjOplhseF5xfWGyJJ+Gpk5KGgpu9TbCuP+ShNklkdnCt90DaEjHhm5FKGnRgWqLdyzQA9Yk1ofiprWzJ5jT8wx0NkrOoQnPokGDwmNQuG8uZVUy4/DwCDHRYUWrgbt5ZXJqzL7EqMYKYy2j9h7wslu1WJgqw0SU0fabEPsx+WAA1dyCpfp/fp57itrWvMESqWr7fdWb9sul91la9RTW2lj5IdrRozYXg3IvLW59JKP7Rf72Yl0O6npPzRcIO0fDqK8uStdOF2pCYl9XjXCPjp015I/Wh+pVcRsFYqTW6EyvR2ntconeFjhpczBHpIIBTjCCAUqgAwIB
15568[14525d10]: EqKCAUEEggE9iJmRjcezmVd9KolHoIEUIkqU6jWN5UL4ovYSstB4Ps0SNi/jnwzl6RmKz9MLuH+PNF32PKj8NB/hG4zkHUVjdTNH9oBJQDC922UVdAKUs3JgsAV+pRFphkvHHXLMegl70Jf+vxV52rjzBzc/gkDkGrLdYnFp9LrzGksauQ/QCZf2Vy6S1OVLYSU2d9aGgSXJC/yzNqGfO3NqM793wlNmhEzj2+ehFUNJrs060I1mZ4toScR/HuK5TqlqnsZzuiQPJFN6Hdx1cH3jPh8viR2R/kyuhmOiXMUC4uvG/AHk/1CaeZYpSnOJPopP5MkjpAULcTcH89c8DYsjPhG0O0YWrNGsvBZDy61xt5hu3pheOBYcBbxmDX4XdltboTPyFOjHUSPo
15568[14525d10]: tERQSQ1zbWV3ryKvuB5cSjJ+NDC4FB0C/Us=

5008[14525bc0]: ReadNextLine [stream=189ea928 nb=212 needmore=0]
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:CreateNewLineFromSocket: + YIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARucmbJXNaXWheGuq5j9WYIp0ahIPMLM/rPpldpZFy7tH8w1GBiCpFpujnmt6DzeiUGssmoexLGQmLjF8+A+YJq1CviaRNzh4MnZagqiscWAjTGTN5r1SAZjnuiZ5NI9jnVyfbOnQK6qOHIV3P3bEg=

5008[14525bc0]: entering nsAuthSSPI::GetNextToken()
5008[14525bc0]: InitializeSecurityContext: succeeded.
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:SendData: 

15568[14525d10]: ReadNextLine [stream=189eab08 nb=212 needmore=0]
15568[14525d10]: 19f25000:exchange.iat.intern:NA:CreateNewLineFromSocket: + YIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARu+OC1F8HLtncx5eC7yCcR1KkvmnQhAdUXnHcuXv6iYfcu4szbYHLuNOhX6GZg4Zjqqb/1jlyniWKPyIEyR/A9rbuydKKPu6FW8OBUlUVPLJYblPyFtUwVlF/fpjcemmCTg1gqqytbDePcL3TkYE4=

5008[14525bc0]: ReadNextLine [stream=189ea928 nb=48 needmore=0]
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:CreateNewLineFromSocket: + BQQF/wAMAAwAAAAAVj3BFMoZBL6rEF3LxGaqzAEALuA=

15568[14525d10]: entering nsAuthSSPI::GetNextToken()
15568[14525d10]: InitializeSecurityContext: succeeded.
15568[14525d10]: 19f25000:exchange.iat.intern:NA:SendData: 

15568[14525d10]: ReadNextLine [stream=189eab08 nb=48 needmore=0]
15568[14525d10]: 19f25000:exchange.iat.intern:NA:CreateNewLineFromSocket: + BQQF/wAMAAwAAAAAVj3B70+9MhgRf68jEwdHEwEALuA=

5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:SendData: BQQE/wAMAAwAAAAASIImYf5xrVtZkL+0MLUbsAEAAABidW5r

15568[14525d10]: 19f25000:exchange.iat.intern:NA:SendData: BQQE/wAMAAwAAAAASIImYB2RLg9WC6p4rplSCgEAAABidW5r

5008[14525bc0]: ReadNextLine [stream=189ea928 nb=30 needmore=0]
5008[14525bc0]: 18a2f800:exchange.iat.intern:NA:CreateNewLineFromSocket: 4 OK AUTHENTICATE completed.

5008[14525bc0]: login succeeded
15568[14525d10]: ReadNextLine [stream=189eab08 nb=30 needmore=0]
15568[14525d10]: 19f25000:exchange.iat.intern:NA:CreateNewLineFromSocket: 4 OK AUTHENTICATE completed.

15568[14525d10]: login succeeded
...

The problem lies in the detection of the authentication methods supported by the server:

Thunderbird 38.1.0 detects: IMAP auth: server caps  0x486231, pref 0x1000000, failed 0x0, avail caps 0x0
Thunderbird 31.6.0 detects: IMAP auth: server caps 0x1587235, pref 0x0, failed 0x1000000, avail caps 0x0

Possibly this is caused by the IMAP server disabling all auth methods before STARTTLS.  Following is the output of the IMAP CAPABILITY command before STARTTLS, obtained using "echo 1 CAPABILITY | nc -C exchange 143":

* OK The Microsoft Exchange IMAP4 service is ready.
* CAPABILITY IMAP4 IMAP4rev1 LOGINDISABLED STARTTLS UIDPLUS CHILDREN IDLE NAMESPACE LITERAL+
1 OK CAPABILITY completed.

And after STARTTLS, obtained using "openssl.exe s_client -starttls imap -host exchange -port 143 -crlf":

* CAPABILITY IMAP4 IMAP4rev1 AUTH=NTLM AUTH=GSSAPI AUTH=PLAIN UIDPLUS CHILDREN IDLE NAMESPACE LITERAL+
1 OK CAPABILITY completed.

So this bug is unrelated to https://bugzilla.mozilla.org/show_bug.cgi?id=1174159#c20 .
I can confirm that this is an issue with Courier IMAP 4.15 on the server side with STARTTLS required from the server. Update broke all of our email clients this morning. Reverted to an earlier version of Thunderbird (38.0.1) to fix the issue and turned automatic updates off throughout our environment.

It appears to be the issue that is outlined above. I.e.: When STARTTLS is required (all auth methods disabled before STARTTLS), Thunderbird does not properly detect the authentication methods as it used to do.

Capabilities look like this:

* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE STARTTLS LOGINDISABLED] Courier-IMAP ready. Copyright 1998-2011 Double Precision, Inc.  See COPYING for distribution information.

And after using openssl to do the starttls, then issuing '1 CAPABILITY' to the server:

* CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN


This is a fairly serious issue for anyone with a setup that requires STARTTLS, it would appear, as it renders Thunderbird entirely non-functional and there is no workaround other than to not require STARTTLS, which would be a bad thing from a security perspective.
I've seem several reports now of issues like this. For now, I'll make this bug the active bug for this issue until we can determine if there are multiple unrelated patterns.

To really fix the issue, what I need is a test account on a server demonstrating the issue, so that I can duplicate the issue. If you are prepared to offer that, please send account login information to rkent@caspia.com

Otherwise, two things would be useful:

1) Please confirm whether your issue exists on version 38.0.1 Comment 1 says this affects 38.1.0 but not 38.0.1  Can you confirm that for your issue?

2) Additional logs such as those in comment 0 would be useful, but best to add as attachments to the bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sent email account information to rkent@caspia.com as requested. Yes, confirmed affects 38.1.0 but not 38.0.1.
The logs in comment 0 show that, when it works, there is a second line of capability received from the server after STARTTLS is initiated, which adds in additional capabilities. We are not seeing that in the failed version.

That might also explain why we are getting different reports with different types of failed logins.

Credentials received, so I should be able to sort this out.
Excellent. Please let me know if there's anything further I can do to assist and/or if server-side changes are recommended.
Component: Untriaged → Networking: IMAP
Product: Thunderbird → MailNews Core
Blocks: 1183650
For the test case provided in comment 4, here is an analysis.

The issue is a result of the fix for the Logjam vulnerability, Bug 1138554 (which applies to NSS, the actual patch landing this in mozilla-esr38 is https://hg.mozilla.org/releases/mozilla-esr38/rev/c55019659cf3 bug 1176097). I confirmed this by compiling Thunderbird 38 with and without this patch. These changes are all in core mozilla code, not in comm-esr38 code which is controlled by the Thunderbird team.

Essentially, the length of a DHE key must be 1023 bits or greater, for the test case it is only 768 bits. When the connection fails, in the error console I get the message:

Timestamp: 7/16/2015 9:28:04 PM
Error: An error occurred during a connection to mail.xxxxx.com:143.
SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message.
(Error code: ssl_error_weak_server_ephemeral_dh_key)

The Firefox security team has been WONTFIXing bugs that complain about breakage due to this, their position is that the affected sites should update to more secure certificates.

In many cases there is a workaround available. Firefox addon "Disable DHE" works fine with Thunderbird, though you have to manually download and install it since the addon is only flagged as being usable for Firefox in AMO. Alternatively, all that addon does is set the value of these four preferences to false, and you can do that in the Config Editor:

  security.ssl3.dhe_rsa_aes_128_sha
  security.ssl3.dhe_rsa_aes_256_sha
  security.ssl3.dhe_dss_aes_128_sha
  security.ssl3.dhe_rsa_des_ede3_sha

This will fail if you only have dhe ciphers available, but in the test case it solved the problem.

If your site works in 38.0.1 but not in 38.1.0, then this is likely the problem you have. I would appreciate confirmations from people that a) they see the error in the error console when connection fails, and 2) the addon (or changes to prefs) does or does not fix their issue. I also only tested for Imap, I would appreciate comments on SMTP and POP3 as well.

I strongly suspect that the Thunderbird team is also going to WONTFIX this issue.
I can confirm my issue happens also with TB 38.0.1, the logs look the same like for 38.1.0.

I can't tell what TLS settings my TB negotiates, but from my logs can be seen that STARTTLS is successful, so my problem is unrelated to LogJam/DHE group size.

I attached a log for SMTP.  From this I conclude that SMTP has no actual problem, just that TB tries to save the message being sent though IMAP, fails and aborts.

I can't offer a test account, because our IMAP is offered only internally.
My version is 38.1.0, when I open Thunderbird, it stays waiting for login dialogs.

My server parameters are:
IMAP server (Zimbra)
Port: 993
Secure connection: SSL/TLS
Auth. mode: nornal password
Check for new mail on startup

Got the error ssl_error_weak_serverephemeral_dh_key

I also have a warning (translated from Catalan):
This site uses a SHA-1 certificate. We recommend to use certificates with signature algorithms that use "hash" functions more secure than SHA-1.
Marca horĂ ria: 17/07/2015 10:27:24

Fitxer font: https://aus4.mozilla.org/update/3/Thunderbird/38.1.0/20150707103124/WINNT_x86-msvc/ca/release/Windows_NT%206.3.0.0%20(x64)/default/default/update.xml?force=1

Updated to false the two first keys, I can't see:

  security.ssl3.dhe_dss_aes_128_sha
  security.ssl3.dhe_rsa_des_ede3_sha

Restarted Thunderbird
Fixed the problem, it works now!!
Thank's Kent!!

Now, the question is when we will be able to enable those keys.
Suggestion:

I think that, if Mozilla Team WONTFIXes this issue, Thinderbird should show al least a warning/error dialog, an give an easy method to "Disable DHE" from config menus.
Confirmed that 38.1.0 works after setting the following options to false:

security.ssl3.dhe_rsa_aes_128_sha
security.ssl3.dhe_rsa_aes_256_sha

I greatly appreciate the time to look into this and the detailed explanation!


Personally, I wish the mozilla team would quit breaking client-side SSL support in the name of 'security' - it's been a real problem with older (and by 'older', I mean like 2-3 years old, not ancient) appliance-based systems (SOHO firewalls, VoIP ATAs, Storage systems and network equipment that have HTTPS based management interfaces), out-of-band server cards, etc. on the Firefox side. Really need to provide dialogs and options to continue after appropriate warnings, not just break stuff silently.

Also, SHA2 is not expected to be fully implemented for a while yet (I believe 12/31 of 2015 is the sunset for SHA1 certs from a Google/Microsoft/etc. perspective), so it's ridiculous to expect that everything in the world is done this far ahead of time (esp. mail servers as opposed to websites) ... 

This is a different issue for a different place, and a philosophical problem rather than a purely technical one. However, this philosophical problem has the practical implication that Firefox and Thunderbird become less viable all the time unless all you ever do is surf websites and don't have browser-based application requirements. Just my 2 cents ... 

Will experiment with whether there is a way to provide a longer DH ephemeral key with these ciphers and see what that does (probably by converting to a SHA2 signed cert on mail servers earlier than planned). In the meantime, though, this is a reasonable workaround at least.
Follow on to comment 12 in case it helps someone ... 

The issue (specific to courier IMAP) is that the TLS dhparams DSS PEM file made by mkdhparams is 768 bit by default.

This problem can be resolved server-side (without the need for the client-side changes to disable ciphers) on Courier IMAP as follows:

1. Either set the environment variable BITS to 1024 or edit /usr/sbin/mkdhparams and change from 768 to 1024.

2. Re-run mkdhparams to generate a new PEM file (/usr/share/dhparams.pem by default)

3. Restart courier IMAP

So, this issue has nothing to do with the 'security' of the SSL certificate itself or the signing algorithm (SHA1 versus SHA2), but rather is related specifically to the length of the DH Params DSS key that is used to generate the ephemeral key during DHE.
The procedure described in comment 13 has removed the problem that I described for bug 1183650 comment 4 (IMAP SSL STARTTLS against courier-imap-ssl on Debian 8.1) No further reconfiguration or confirmation was neccessary on client-side.

Thank you very much.
I have the same problem as have upgraded to 38.1.0 last friday. Cannot find a way into the code to make these changes. Can someone please help me with either reverting to a previous version or how to apply this fix.
Thanks in advance
same here. Thunderbird beta (38.0) is working correctly.

logs from postfix, when connecting and adding new account with TB 38.1

Jul 21 09:47:18 localhost postfix/smtpd[2233]: connect from XXXX
Jul 21 09:47:18 localhost postfix/smtpd[2228]: improper command pipelining after EHLO from XXXX: QUIT\r\n
Jul 21 09:47:18 localhost postfix/smtpd[2228]: disconnect from XXXX ehlo=1 quit=1 commands=2
Jul 21 09:47:18 localhost postfix/smtpd[2233]: improper command pipelining after EHLO from XXXX: QUIT\r\n
Jul 21 09:47:18 localhost postfix/smtpd[2233]: disconnect from XXXX ehlo=1 quit=1 commands=2

and if account is already existing.. no errors is displayed, just no connection is made and no emails pulled or pushed.
The first two were not enough, I needed all 3 set to false for smtps to work

  security.ssl3.dhe_rsa_aes_128_sha
  security.ssl3.dhe_rsa_aes_256_sha

  security.ssl3.dhe_rsa_des_ede3_sha
Severity: normal → major
Keywords: regression
Whiteboard: [workaround: comment 7, 12-13, 17 - though not great security]
security.ssl3.dhe_rsa_aes_128_sha;false
security.ssl3.dhe_rsa_aes_256_sha;false

Has not fixed the problem.
I do not, however, have 
security.ssl3.dhe_rsa_des_ede3_sha

So cannot change the parameter.
Have also tried to change the below to false and also didn't solve. So reverted.
security.ssl3.rsa_des_ede3_sha;true

I also do not have 

security.ssl3.dhe_dss_aes_128_sha
security.ssl3.dhe_rsa_des_ede3_sha
 as indicated in comment 7
So still have a broken system.

Any other suggestions please?
If you don't have certain parameters defined by default, the proper action is to add them.
Thanks Kent.
I'm VERY new to this.
How do I go about adding new parameters. Can't find an "ADD" button.
(In reply to info from comment #20)
> Thanks Kent.
> I'm VERY new to this.
> How do I go about adding new parameters. Can't find an "ADD" button.

While in the Config Editor, right-click on any entry, and there should be a New button. Create a New boolean.
Thanks Kent.
Just out of curiousity - if the parameter is NOT in my Config Editor and previous requirements have been true (now set to false) wouldn't that obviate the need to INCLUDE them in the parameters.
Sorry again for my naivete.
security.ssl3.dhe_dss_aes_128_sha;false
security.ssl3.dhe_rsa_aes_128_sha;false
security.ssl3.dhe_rsa_aes_256_sha;false
security.ssl3.dhe_rsa_des_ede3_sha;false

Have added the ones I did not have as above and still no go.
Mine is POP3. Could that be an issue?

I can send from mine - just not receive.
I'm having the same problem with Thunderbird 38.1.0.

TB hangs ("connected to...") on attempt to login to POP mail server via port 995 with secure SSL/TLS connection.

The server is hosted with LiquidWeb.
- The server has "GlobalSign nv-sa" SSL certificate valid till 03/08/2016.
- OS: CENTOS 6.6 x86_64 standard
- exim-4.85-8.cp1148.x86_64
- openssl-1.0.1e-30.el6.11.x86_64

Let me know if anyone needs any further details and/or a test email account on the server.

Thank you.
I had problems with 38.0.1 was able to retrieve IMAP gmail when first started today and then after initial download all my folders disappeared and no longer appeared on the subscription list.  I still get mail delivered to my Inbox.  Of course rules error because they can no longer find the other folders.  I still retain the Inbox, Junk, Trash (which hasn't worked and has just become a regular folder with no ability to "empty" since the 23rd) and then the [GMail] with subfolder Junk.
Bug 1183650 comment 29 shows a confirmation that Liquidweb is showing a 768 bit DHE temp key, which is being rejected by Thunderbird 38.1.0 (and is the subject of this bug).
Attached patch Allow 768 bit DHE parameter — — Splinter Review
We're getting a lot of complaints about servers failing with the 1024 bit DHE limit, and are considering lowering that to 782 bits in Thunderbird 38.2.0  Comments? There was discussion of the pros and cons of different limits (though focused on websites) in bug 1138554
Attachment #8638789 - Flags: feedback?(wtc)
Attachment #8638789 - Flags: feedback?(mkmelin+mozilla)
Attachment #8638789 - Flags: feedback?(martin.thomson)
Attachment #8638789 - Flags: feedback?(abillings)
Attachment #8638789 - Flags: feedback?(Pidgeot18)
Thanks for Thunderbird and to those working on this bug!  Thanks to Christian (comment 13) I was able to resolve this problem for Early Bird Thunderbird (Windows 7, installed from 40.0b1-candidates/build3/win32/en-GB/ an hour ago) without altering any settings.  The steps for my Courier IMAP server (Debian 8.1 package) were:

1 - Alter /usr/lib/courier/mkdhparams line "BITS=768" to "BITS=1024".
2 - Run this script, which creates a new /etc/courier/dhparams.pem .
3 - /usr/lib/courier/imapd restart

Search engine bait: /var/log/mail.info imapd-ssl: couriertls: accept: error:14094417:SSL routines:SSL3_READ_BYTES:sslv3 alert illegal parameter
Comment on attachment 8638789 [details] [diff] [review]
Allow 768 bit DHE parameter

Review of attachment 8638789 [details] [diff] [review]:
-----------------------------------------------------------------

Direct those users that complain here: https://addons.mozilla.org/en-US/firefox/addon/disable-dhe/  They lose PFS, but aren't completely vulnerable.

Also, this is against an old NSS version.
Attachment #8638789 - Flags: feedback?(martin.thomson) → feedback-
Comment on attachment 8638789 [details] [diff] [review]
Allow 768 bit DHE parameter

I was not very clear on the proposal for this patch. This is a proposal for a patch to the THUNDERBIRD_38_VERBRANCH of mozilla-esr38, which is used to build Thunderbird 38, to give servers a little more time to upgrade their security configuration. Note this is the same approach currently being taken by OpenSSL as I understand it.
An update. I've contacted LiquidWeb support vis-a-vis the issue, and this is what they promptly did: "Your server was in fact using a 768 bit temp key for IMAP and POP3 connections. I have generated a new 2048 bit key. You should now be able to successfully retrieve your emails. Please let me know if this resolved your issue."

I've installed Thunderbird 38.1.0, and it works fine now.
Attachment #8638789 - Flags: feedback?(abillings)
Comment on attachment 8638789 [details] [diff] [review]
Allow 768 bit DHE parameter

Review of attachment 8638789 [details] [diff] [review]:
-----------------------------------------------------------------

I don't follow SSL or crypto anywhere near close enough to make a well-informed decision here. I'd rather leave this to a more experienced NSS or #security guru to make the decision.
Attachment #8638789 - Flags: feedback?(Pidgeot18)
So I floated the trial balloon, both here and to thunderbird drivers, and there is just not enough support to do anything. As I said in comment 7 the probable result is WONTFIX, so let's just go there.

If you have this issue, you'll need to update your server, or convince your provider to do that as in comment 34.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Comment on attachment 8638789 [details] [diff] [review]
Allow 768 bit DHE parameter

Not enough support, so we can drop this request.
Attachment #8638789 - Flags: feedback?(wtc)
Attachment #8638789 - Flags: feedback?(mkmelin+mozilla)
Similar problem here using Thunderbird 1:31.8.0 on Kubuntu 15.04. Email is POP using SSL/TLS.

Thunderbird was working fine until the update to 1:31.8.0 on 21 July. Now Thunderbird says no messages on the mail server, but there are messages waiting there. Attempts to reset password fail. (1. delete password, but Thunderbird doesn't ask for a new one on restart. 2. Attempts to create new account fails with Thunderbird saying username or password is incorrect, but I double checked these to be ok.)

The mail server host admin advise key size is 2048 bits, so perhaps key size is not the problem?
Peter, see for example https://bugzilla.mozilla.org/show_bug.cgi?id=1187297#c4 which shows how openssl (must be version 1.2) can be used to show the issue with temp keys. You can run that test, or if you report your server information and it is publicly accessible, others can run it for you. There is a lot of confusion about which key length is being discussed with statements like "mail server host admin advise key size is 2048 bits"

There are also other possible issues that can cause connection failure, but it it starts in 31.8.0 or 38.1.0 is is likely the DHE Logjam issue, which is this bug.
peter@hook:~$ openssl s_client -crlf -connect twins.nocdirect.com:995
CONNECTED(00000003)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/OU=Domain Control Validated/OU=EssentialSSL Wildcard/CN=*.nocdirect.com
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=EssentialSSL Wildcard/CN=*.nocdirect.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 4958 bytes and written 461 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 55594300AB7E9206CC5C7A07EA61AE603D0C2320B92AAEAE6691EDD38EEEA7ED
    Session-ID-ctx: 
    Master-Key: DD86B7FFD953FDDB4C3938C4C756426B3FE158E1012F2ED3907929B0D61DC08F7CEE82BFDE05ECB902579D817E15FD25
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1437872321
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
+OK Hello there.
The system admin guys changed some settings on the mail server, and Thunderbird is working again!
same here, changed mailserver config (upgraded dhparams.pem from 768 to 1024) and now is everything ok. Still, Thunderbird SHOULD give some message or warning instead just silently failing.
I am curious how comes that disabling these
security.ssl3.dhe_rsa_aes_128_sha
security.ssl3.dhe_rsa_aes_256_sha
makes Thunderbird 38.1.0 work even if the server key is still 768 bit?
(In reply to Christian from comment #13)
> Follow on to comment 12 in case it helps someone ... 
> 
> The issue (specific to courier IMAP) is that the TLS dhparams DSS PEM file
> made by mkdhparams is 768 bit by default.
> 
> This problem can be resolved server-side (without the need for the
> client-side changes to disable ciphers) on Courier IMAP as follows:
> 
> 1. Either set the environment variable BITS to 1024 or edit
> /usr/sbin/mkdhparams and change from 768 to 1024.
> 
> 2. Re-run mkdhparams to generate a new PEM file (/usr/share/dhparams.pem by
> default)
> 
> 3. Restart courier IMAP
> 
> So, this issue has nothing to do with the 'security' of the SSL certificate
> itself or the signing algorithm (SHA1 versus SHA2), but rather is related
> specifically to the length of the DH Params DSS key that is used to generate
> the ephemeral key during DHE.

Thanks a lot for this tip!!!
I just wanted to clarify it a bit: you should set DH_BITS, not BITS if you aren't modifying the file itself (which you shouldn't really do).
So, the correct command which should be run by a superuser to fix this issue for Courier mail server under Debian is:
DH_BITS=1024 mkdhparams

Upon executing it, you should see output like this:

512 semi-random bytes loaded
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
(and a lot of dots and pluses below)

If you don't see any output, delete the /etc/courier/dhparams.pem file and re-run this command.
I don't see my IMAP gMail folders showing up in my TB subscription so something is not right!  I see more folders than I did the other day but they are all basic gMail folders.  My other self-created folders which propagated to gMail a long time ago are no longer accessible by TB.
Please reopen with the following clarifying description:

Thunderbird IMAP unhelpful reporting of weak DH-params

When an IMAP server has been configured or built with "weak" ephemeral Diffie-Hellman paramaters, which until recently were considered adequate, Thunderbird gives (and logs) highly misleading error messages referring to unrelated aspects of the server configuration.

While the countermeasures against the LogJam attack prevent making an SSL/TLS connection to such servers, the error reporting should be clear as to what error is actually occurring (connection aborted by NSS due to DH key length less than 1024), not nonsense messages resulting from IMAP code ignoring the failure and attempting to communicate over an already dead connection.

This is much more urgent than normal error message issues, as the upgrade from Tb 38.0 to Tb 38.1 introduced this failure mode for many existing real world servers.  Regardless of the security reasoning, this leaves Tb 38.1 in an unreleasable state, and it needs to be fixed or recalled.
I've just re-loaded 36.0 and all fixed.
Not helpful as far as 38.1.0 but it has solved my issues. All emails have downloaded correctly and are accessible.
No longer blocks: 1187797
Depends on: 1187797
(In reply to Jakob Bohm from comment #47)
> Please reopen with the following clarifying description:

Thanks for the description! I chose to open a separate issue instead, since this one has too many comments, at least in my opinion. I could probably mark it as a duplicate of the new one.
I'm not happy that "my" bug was hijacked by the LogJam issue.  May I remind everyone that my problem is unrelated to DHE group size, but a problem with authentication method detection after STARTTLS?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Hi Keith and Rimas and everyone else,

IMAP was working in 31.5.0, but not working in 38.1.0 and below are my errors.

I apologzie for hijacking this bug and I don't know if this is the same issue, however my Host/ISP isn't fixing this issue and I don't want to change the referenced settings.

Does anyone know, do I need to get a new host? I don't know anything about logjam, but I've seen a few posts with people saying their host/ISP fixed this issue server-side rather than client-side. If my host is going to make me fix this client-side, I'd rather just get a new host because Mozilla's position this is insecure, right?

My host says this issue is due to a Mozilla bug, but my host won't look into this and won't look into acceptable server-side fixes.

Can anyone advise? Thanks
---
SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message.

(Error code: ssl_error_weak_server_ephemeral_dh_key)
---
Warning: This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.
(In reply to logjamthis from comment #51)
> Hi Keith and Rimas and everyone else,
> 
> IMAP was working in 31.5.0, but not working in 38.1.0 and below are my
> errors.
> 
> I apologzie for hijacking this bug and I don't know if this is the same
> issue, however my Host/ISP isn't fixing this issue and I don't want to
> change the referenced settings.
> 
> Does anyone know, do I need to get a new host? 

Yes, if they are not going to change and you don't wish to downgrade.

> I don't know anything about
> logjam, but I've seen a few posts with people saying their host/ISP fixed
> this issue server-side rather than client-side. If my host is going to make
> me fix this client-side, I'd rather just get a new host because Mozilla's
> position this is insecure, right?
> 
> My host says this issue is due to a Mozilla bug, but my host won't look into
> this and won't look into acceptable server-side fixes.

They are of course being dorks. And they are also in the small minority with respect to server settings. The server and client solutions are described here, should you wish to reference them :
https://weakdh.org/#sysadmin
http://thunderbirdtweaks.blogspot.com.au/2015/07/logjam-and-thunderbird.html
Comment #52 (and the decision making process by the NSS team) is wrong at every point:

1. At least one big server vendor (the Debian project) ships with 768 bit DH groups in some IMAP implementations in its latest OS release.  While web servers are more focused on rolling out such changes, mail servers get much less vendor attention in the SSL/TLS department.

2. The blogpost on thunderbirdtweaks is insultingly useless, wasting time talking about export ciphers (NOT THIS ISSUE), 512 bit keys (NOT THIS ISSUE) and Web Server configuration (NOT THIS ISSUE).

3. At least one other SSL/TLS library (The OpenSSL project) decided when LogJam occurred, that they would quickly enforce a 768 bit minimum, but delay the 1024 bit minimum until the many server products with compiled in 768 bit DH parameters had been given a reasonable time to roll out updates globally.  In contrast, the NSS team went overboard and set the bar at 1024 bits almost instantly, leaving a lot of production systems dead in the water, forcing unencrypted connections etc. as desperate workarounds.

While huge mail providers should go the extra mile and manually patch their systems even if their vendor won't, the NSS team is also being dorks by forcing no security where adequate security is available.
Hi Keith, Rimas, Jakob, and Wayne,

I appreciate the responses and will look them over. I thought this was server-side, but wasn't sure. I'm frustrated with my host but not 100% sure if changing the DH_BITS value will fix this and that's because I don't know much about this issue.

I changed those 2 values referenced, security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha, but I don't feel comfortable changing these values if Mozilla sets them at that default. Until I hear a community consensus that Mozilla is flat out wrong, I think Mozilla made the right choice.

Again, thanks for the response, I didn't know what to do or who to ask or where to go for help. And as I said my host was not helpful.
I was having trouble from when Thunderbird updated on 21 July, until the host company (jaguarpc.com) made some adjustments on the server side. I don't know what changes they did. But it wasn't key length, which was 2048 when I was having trouble and 2048 after they made the changes that fixed things.
Hi Peter and all,

I referenced this bug with my host and they still won't fix. I don't want to spend more time on this because I still don't know 100% what is going on and it's unfortunate more clarity isn't easily attainable. Any advice is appreciated. My host is saying they use 2048-bit keys but I don't think that's the exact issue, I don't know what the DH_BITS value is, but that seems to be the issue and my host won't look into this.
(In reply to Jakob Bohm from comment #53)
> Comment #52 (and the decision making process by the NSS team) is wrong at
> every point:
> 
> 1. At least one big server vendor (the Debian project) ships with 768 bit DH
> groups in some IMAP implementations in its latest OS release.  While web
> servers are more focused on rolling out such changes, mail servers get much
> less vendor attention in the SSL/TLS department.
> 
> 2. The blogpost on thunderbirdtweaks is insultingly useless, wasting time
> talking about export ciphers (NOT THIS ISSUE), 512 bit keys (NOT THIS ISSUE)
> and Web Server configuration (NOT THIS ISSUE).
> 
> 3. At least one other SSL/TLS library (The OpenSSL project) decided when
> LogJam occurred, that they would quickly enforce a 768 bit minimum, but
> delay the 1024 bit minimum until the many server products with compiled in
> 768 bit DH parameters had been given a reasonable time to roll out updates
> globally.  In contrast, the NSS team went overboard and set the bar at 1024
> bits almost instantly, leaving a lot of production systems dead in the
> water, forcing unencrypted connections etc. as desperate workarounds.
> 
> While huge mail providers should go the extra mile and manually patch their
> systems even if their vendor won't, the NSS team is also being dorks by
> forcing no security where adequate security is available.

I suggested 768-bit DHE for HTTP too because of JSSE, and what is even worse is that it was released about two weeks before Oracle released their patch for paid customers (before which there was no other choice).
>Oracle released their patch for paid customers (before which there was no other choice).

I am talking about Java 6/7 only of course (Java 8 was already fixed).
(In reply to logjamthis from comment #54)
> 
> I changed those 2 values referenced, security.ssl3.dhe_rsa_aes_128_sha and
> security.ssl3.dhe_rsa_aes_256_sha, but I don't feel comfortable changing
> these values if Mozilla sets them at that default. Until I hear a community
> consensus that Mozilla is flat out wrong, I think Mozilla made the right
> choice.
> 

I don't agree with the assessment in the whiteboard "though not great security" in using the workaround in comment 7. These workarounds were originally proposed to eliminate the Logjam vulnerability on unpatched systems by disallowing the use of the affected ciphers, and in that case the security code uses another cipher (if available) that is not subject to Logjam. I am not aware of any comments that this results in compromised security, but I am not a security expert.

Re comment 57 "I suggested 768-bit DHE ..." we had an internal discussion of this a week ago, see comment 36. 

Re comment 56 and "My host is saying they use 2048-bit keys but I don't think that's the exact issue, I don't know what the DH_BITS value is, but that seems to be the issue" I encourage you once again to look at my comment 39. YOU MUST USE THE NEWEST OPENSSL FOR THIS to see the line "Server Temp Key: DH, 768 bits" which is the critical issue. If you don't see that line at all, something is not right with your diagnostic (unless you are not using DH). A fixed system will show "Server Temp Key: DH, 1024 bits" If you report the URL and protocol that you are trying I can run this test for you.

If your "host won't look into this" then they are refusing to take the time to understand their logjam vulnerability even after you pointed this out to them. Though I have sympathy for people running private email systems who are being slammed by this, I do not have sympathy for public providers who won't fix their broken infrastructure. Consider switching providers, or just run without STARTTLS if security is not important.
(In reply to Michael Bunk from comment #50)
> I'm not happy that "my" bug was hijacked by the LogJam issue.  May I remind
> everyone that my problem is unrelated to DHE group size, but a problem with
> authentication method detection after STARTTLS?

Michael, in comment 2 I made it clear that we would use this bug as the central bug for what was then an unknown authentication issue, and which I still suspect is what you are seeing (see comment 39 for ways to show this). I have the authority to make these determinations (as a review peer for Mailnews, and overall Chair of the Thunderbird project). In the discussions since, a particular issue has been identified with this bug (the 512 or 784 bit temp DH key), many comments received on that, and a decision made that we are not going to take any action in Thunderbird to alleviate the problems with that, hence the WONTFIX. If comment 2 made a false guess as to your problem, well I regret that it turned out that way, but that is how we have to do things sometimes. I have to focus the discussion to make progress.

If you still believe that your issue is unrelated to the DH temp key issue, or you wish to propose a particular variation on how to approach the issues with this, unfortunately what you will need to do is to open a new bug, perhaps by cloning this bug.  Do not reopen this bug without discussing it here first. Although you have certain special considerations as the bug opener, the bug does not belong to you, it is a public item.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → WONTFIX
(In reply to Kent James (:rkent) from comment #59)
> I don't agree with the assessment in the whiteboard "though not great
> security" in using the workaround in comment 7. These workarounds were
> originally proposed to eliminate the Logjam vulnerability on unpatched
> systems by disallowing the use of the affected ciphers, and in that case the
> security code uses another cipher (if available) that is not subject to
> Logjam. I am not aware of any comments that this results in compromised
> security, but I am not a security expert.

Hi Kent and everybody else here, I'm not a security expert either, does anyone know, does this issue appear because Thunderbird is enforcing DHE-keys >768-bit whether or not DHE would have been used?


> Re comment 56 and "My host is saying they use 2048-bit keys but I don't
> think that's the exact issue, I don't know what the DH_BITS value is, but
> that seems to be the issue" I encourage you once again to look at my comment
> 39. YOU MUST USE THE NEWEST OPENSSL FOR THIS to see the line "Server Temp
> Key: DH, 768 bits" which is the critical issue. If you don't see that line
> at all, something is not right with your diagnostic (unless you are not
> using DH). A fixed system will show "Server Temp Key: DH, 1024 bits" If you
> report the URL and protocol that you are trying I can run this test for you.

I ran:
openssl s_client -crlf -connect myghost_address:myghost_port | grep "Server Temp Key"

And got this:
verify return:1
Server Temp Key: DH, 768 bits

Can anyone let me know if this provides more information to form a compete conclusion for what my host is doing wrong?


> If your "host won't look into this" then they are refusing to take the time
> to understand their logjam vulnerability even after you pointed this out to
> them. Though I have sympathy for people running private email systems who
> are being slammed by this, I do not have sympathy for public providers who
> won't fix their broken infrastructure. Consider switching providers, or just
> run without STARTTLS if security is not important.

I'm still trying to find out what exactly logjam is and what's going on, however I pointed this bug (web page) out to my host multiple times, I'm done doing their job for them, and I think I need a new host. My biggest issue is, how do I know if any given host has this issue when my current host won't even let me know what their DH_BITS value is???

Thank you to all here.
(In reply to logjamthis from comment #61)
> I ran:
> openssl s_client -crlf -connect myghost_address:myghost_port | grep "Server
> Temp Key"
> 
> And got this:
> verify return:1
> Server Temp Key: DH, 768 bits
> 
> Can anyone let me know if this provides more information to form a compete
> conclusion for what my host is doing wrong?

That shows that your server has not fixed the issue. You need at least 1023 bits there now after the patches for Logjam landed.

There has been lots of discussion of what Logjam is, and how to fix it, on the internet and in these bugs.
No Mr. logjamthis: It means that DHE was actually being used (by both Thunderbird and the test), and only then was it detected that the server provided a 768 bit key where Thunderbird now enforces at least 1024.

So the solutions are any of the following:

- Change the server to use at least 1024 bits for its DH parameters (which are different from its certificate), note that at least one older client will refuse to talk servers offering DH parameters with more than 1024 bits.

- Change Thunderbird settings to not try DHE at all, thus making the server not offer any DH parameters (of any size).

There has unfortunately been a lot of misinformation and mistakes in these bugs.
(In reply to Kent James (:rkent) from comment #62)
> That shows that your server has not fixed the issue. You need at least 1023
> bits there now after the patches for Logjam landed.

(In reply to Jakob Bohm from comment #63)
> No Mr. logjamthis: It means that DHE was actually being used (by both
> Thunderbird and the test), and only then was it detected that the server
> provided a 768 bit key where Thunderbird now enforces at least 1024.
> 
> So the solutions are any of the following:
> 
> - Change the server to use at least 1024 bits for its DH parameters (which
> are different from its certificate), note that at least one older client
> will refuse to talk servers offering DH parameters with more than 1024 bits.

Hi Jakob and Kent, so my host isn't practicing good well-known security measures by using at least 1023 bits? Isn't that really bad for them? As a result, does this mean my host is still vulnerable to logjam?


> - Change Thunderbird settings to not try DHE at all, thus making the server
> not offer any DH parameters (of any size).

Jakob, are these the parameters? security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha?


> There has unfortunately been a lot of misinformation and mistakes in these
> bugs.

Thank you both and all for helping and stuff. Cheers!
Note that using 1024-bit DH groups isn't really advisable.  The logjam paper advises that you only do this if you need to be compatible with old software that doesn't support larger DH groups.  If you do that, to be something close to secure you need to change the specific DH group constantly.

Pick a bigger number.  2048 seems to be what people recommend, but if you are concerned about the time it takes to compute, then 1536 is also fine.

In the end, EC is where you want to be; all modern stacks support good EC crypto, so when you upgrade, enable those cipher suites and avoid a whole lot of pain.  256-bit EC is in the order of 100 times faster than 1024-bit crypto on finite fields at worst and much more secure overall.
(In reply to Martin Thomson [:mt:] from comment #65)
> Pick a bigger number.  2048 seems to be what people recommend, but if you
> are concerned about the time it takes to compute, then 1536 is also fine.
> 
> In the end, EC is where you want to be; all modern stacks support good EC
> crypto, so when you upgrade, enable those cipher suites and avoid a whole
> lot of pain.  256-bit EC is in the order of 100 times faster than 1024-bit
> crypto on finite fields at worst and much more secure overall.

Hi Martin, I'm not sure if you are replying to me, however thank you. In relation to logjam, the advice is to use at least 2048 bits?

I'm not 100%, however it seems my host is only using 768-bits and some here seem to think 768 and/or 1024 is fine. It's interesting you and the logjam advice say to use at least 2048-bits. I'm not trying to start an argument, just pointing out what I think might be a possible root cause.

Also, please keep in mind I am with a 3rd party host and can't change anything. I don't know what EC is, can you let me/us know? Thanks.
(In reply to logjamthis from comment #66)
> (In reply to Martin Thomson [:mt:] from comment #65)
> > Pick a bigger number.  2048 seems to be what people recommend, but if you
> > are concerned about the time it takes to compute, then 1536 is also fine.
> > 
> > In the end, EC is where you want to be; all modern stacks support good EC
> > crypto, so when you upgrade, enable those cipher suites and avoid a whole
> > lot of pain.  256-bit EC is in the order of 100 times faster than 1024-bit
> > crypto on finite fields at worst and much more secure overall.
> 
> Hi Martin, I'm not sure if you are replying to me, however thank you. In
> relation to logjam, the advice is to use at least 2048 bits?
> 
> I'm not 100%, however it seems my host is only using 768-bits and some here
> seem to think 768 and/or 1024 is fine. It's interesting you and the logjam
> advice say to use at least 2048-bits. I'm not trying to start an argument,
> just pointing out what I think might be a possible root cause.
1024-bit will work, just not recommended I think.
(In reply to logjamthis from comment #66)
> Also, please keep in mind I am with a 3rd party host and can't change
> anything. I don't know what EC is, can you let me/us know? Thanks.
Elliptic curve encryption (ECDHE), an alternative to DHE.
The easiest thing to do is to move to 2048 - which is just as strong as most certificates (I'm oversimplifying here, of course :).  If you have to stay at 1024, then the https://weakdh.org advice includes some additional steps.

We don't know for certain that 1024 is broken, and the best public information suggests that it is not, but we it isn't strong enough for us to recommend it.  Key agreement protocols require a higher degree of paranoia than other protocols.  An attacker that can capture your traffic now might be able to decrypt it 5 years from now if there are some relatively modest improvements in compute power or cryptanalysis.

EC = elliptic curve.  For the purposes of this, it includes all cipher suites with '_ecdhe_' in the name ('ECDHE' in openssl config strings).

I understand that you can't necessarily get your provider to update, but I wanted to make sure that for those that could, the best advice was available.
this worked for downloading pop messages tb 38.1

set the value of these four preferences to false, and you can do that in the Config Editor:

  security.ssl3.dhe_rsa_aes_128_sha
  security.ssl3.dhe_rsa_aes_256_sha
  security.ssl3.dhe_dss_aes_128_sha
  security.ssl3.dhe_rsa_des_ede3_sha
(In reply to Kent James (:rkent) from comment #7)

Setting the security.ssl3.dhe_* values to false in config editor worked for me in 38.1.0. IMAP and CalDAV both work correctly now. 

It would be great if there were some warning or clear alert message. Not all users have the option of changing providers whenever Thunderbird changes its security policies, and having to hunt down cryptic error messages only makes this more frustrating.
:wsmwk, that article is incorrect:

> The use of the add-on is not a long term solution, and is not a substitute for fixing the server. By using it, you are at risk of a man-in-the-middle attack, but it gives breathing time for the server adminstrator to generate and install better key pairs on the server. 

The only risks with the addon are:
1. you don't get forward secrecy in some cases, even if the server can provide it (if you choose a non-ephemeral suite)
2. you risk not connecting to a site/server at all (if DHE is all they offer)

For Thunderbird, the first is probably the only relevant concern, since you don't have to worry about connecting to lots of sites (if you can't connect with the add-on enabled, then you need to rely on the server admin to fix the server).

Also regarding:
> Disable DHE will not appear in the Thunderbird Add-ons Manager if you search for it from Thunderbird.

I have the keys on the add-on, if there is anything I can do to make it visible to TB users, I'm happy to do that, I just don't know how.
Wayne, see comment #75.
Flags: needinfo?(vseerror)
Having same issue with TB 38.2.0 Toggled settings for 

security.ssl3.dhe_rsa_aes_128_sha
security.ssl3.dhe_rsa_aes_256_sha

and now able to connect to mail server!! Thanks.
even though this bug seems to be ignored I thought I should share the workaround I found in case somebody ever stumbles upon this while researching the problem. I changed the account configuration in Thunderbird from using STARTTLS to static SSL on port 993 and I was able to connect again
I have run into an issue like this (imapd-ssl: couriertls: accept: error:14094417:SSL routines:SSL3_READ_BYTES:sslv3 alert illegal parameter) after upgrading Thunderbird to v38.6.0 on my laptop. I'm not sure what the previous version was but it must have been rather new. I use the machine often (a few weeks apart) and Thunderbird updates itself when new versions emerge.

But: Even though I'm running the same version of Thunderbird on the same Windows version (Windows 10 Home) on my workstation, and even though I've copied my Thunderbird profile folder from my workstation to my laptop so that both the installation and configuration of Thunderbird is (at least ought to be identical) on the two machines, this issue only occurs on my laptop, and it occurs consistently - and I can't reproduce it on my workstation. That sounds very strange to me.
A few comments to my last comment:

1) People have suggested that this is related to using STARTTLS. I don't use STARTTLS for my connections, I use SSL/TLS.
2) Changing the security.ssl3.dhe_* options in the config editor (I can only find the first two of the four mentioned in comment #7) does make Thunderbird work, but I still don't understand why there is no problem on my workstation.
Flags: needinfo?(vseerror)
> but I still don't understand why there is no problem on my workstation.

The problem started occuring on my workstation today after a restart of Thunderbird. I haven't made any changes to Thunderbird (or my profile) since my previous comment other than updating it when it says there's a new version (current version is: 45.0). I don't understand why it suddenly starts to behave like this.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: