Closed Bug 788577 Opened 12 years ago Closed 8 years ago

Can not make an SSL\TSL connection to our Unity Connect Voice Mail server


(Thunderbird :: Security, defect)

15 Branch
Not set


(Not tracked)



(Reporter: masters, Unassigned)



User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120824154833

Steps to reproduce:

Unable to establish a IMAP SSL\TSL connection to our Cisco Unity Connection voice mail server, ever since v13.0

Actual results:

User gets incorrect password or server timed out message

Expected results:

encrypted connection to our server.
Thunderbird versions 9.0.1 and below work.  Versions newer than 9.0.1 are unable to connect to the imap service on the Cisco unity voice mail server when configured to use port 993 & SSL/TLS.  Cursory Google searching indicates a change in how SSL is handled when authenticating.

Newer versions do successfully connect the the server using unencrypted imap, but this is certainly not preferred.

I believe this is a duplicate of 727418.

I am upgrading a working version 9.0.1 to 15.0 right now to attempt to generate the logs requested in 727418.

In 15.0, the line "Checking mail server capabilities..." comes up a the bottom and the blue scroll bar dances from left to right forever.

This is what I believe to be the relevant content from a session log:

[coloccia@status ~]$ more imap-unity.log | grep -v acc7440 | grep -v e37ec40 | grep -v acc5c80 | grep -v 2111f80 | grep -v e37e9c0 | grep -v 210f140
3744[82a40c0]: ImapThreadMainLoop entering [this=75f8000]
3744[82a40c0]: entering
3744[82a40c0]:  = currentUrl
3744[82a40c0]: ReadNextLine [stream=bce2d48 nb=39 needmore=0]
3744[82a40c0]: * OK  UMSS IMAP4rev1 Server Completed
3744[82a40c0]: 1 capability
3744[82a40c0]: ReadNextLine [stream=bce2d48 nb=35 needmore=0]
3744[82a40c0]: * BAD Protocol Error: Invalid Tag
3744[82a40c0]: ReadNextLine [stream=bce2d48 nb=0 needmore=1]
3744[82a40c0]: clearing IMAP_CONNECTION_IS_OPEN - rv = 80004004
3744[82a40c0]: close socket connection
3744[82a40c0]: (null)
3744[82a40c0]: aborting queued urls
3744[82a40c0]: ImapThreadMainLoop leaving [this=75f8000]

I will attach the entire log, it's large and cluttered with another account's successful connection information.  Sorry about that.
entire log is at

it's too large to attach to the ticket.
(In reply to Rick Coloccia from comment #1)
> Thunderbird versions 9.0.1 and below work.  
> Versions newer than 9.0.1 are unable to connect to the imap service (snip)
> 3744[82a40c0]: *
> OK  UMSS IMAP4rev1 Server Completed
> 3744[82a40c0]: 1 capability
> 3744[82a40c0]: *
> BAD Protocol Error: Invalid Tag

It sounds same as or similar to Bug 723109(i.e. problem of bug 702111).
Can you try the workarounds in 723109 ?
I created a batch file to launch tb15:

"c:\program files\Mozilla Thunderbird\thunderbird.exe"

I was then able to successfully connect via imaps (993 with SSL/TLS) to the voice mail server and access messages.

I closed tb15 and relaunched it from the normal shortcut, I was STILL able to access existing messages.  I rebooted, launched tb15 from the normal icon, I could still access existing messages.  I sent myself voicemail, and tb15 was NOT able to get to the new message. 

So after one launch with the workaround, I was able to see old messages, but new ones were not available.

I closed tb, relaunched from the batch file, and then again I was able to access my new voice mail.  

So launching tb from a batch file or otherwise adding NSS_SSL_CBC_RANDOM_IV=0 to my environment works.  This workaround is great for power users, but we have almost 400 users trying to use encrypted imap to access their voice mail.  What can we do to make this workaround scale and be accessible to regular users?

Thanks for all the effort!

(In reply to Rick Coloccia from comment #5)

Problem is roughly:
(1) Server can't work well with request from client who utilizes SSL's
    NSS_SSL_CBC_RANDOM_IV=1. See bug 702111.
(2) Default of NSS_SSL_CBC_RANDOM_IV is 1 nowadays in SSL library.
    NSS_SSL_CBC_RANDOM_IV=1 is solution for CVE-2011-3389 etc.
(3) By fix of bug 665814, Mozilla uses "1/n-1 record splitting" technique
    when NSS_SSL_CBC_RANDOM_IV=1, in order to avoid problem of CVE-2011-3389.

Workaround of NSS_SSL_CBC_RANDOM_IV=0 at client side is to temporalily prohibit client side behavour with NSS_SSL_CBC_RANDOM_IV=1(=="1/n-1 record splitting") until server will works well with it, in order to bypass server side problem of (1). See following KB article.
Correct action is :
 Upgrade server software to a version which supports solution for CVE-2011-3389,
 or enable server software's feature which supports solution for CVE-2011-3389.
Following is web page found by Google Search for "cisco unity connection CVE-2011-3389".
Cisco Unity ver 7 looks affected by the CVE.
Latest Cisco Unity looks ver 9, if "Cisco Unity Connection" in following page is same as "Cisco Unity" in above security alert page by Cisco.
Closed: 8 years ago
Depends on: 723109
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.