Page MenuHomePhorge

"Fatal error: insufficient security" with NSS 3.27.1
Closed, ResolvedPublic

Description

After upgrading NSS to 3.27.1 Thunderbird is not able to connect to Guam anymore. It fails with "SSL_ERROR_INSUFFICIENT_SECURITY_ALERT" and Guam logs "SSL: hello: tls_handshake.erl:170:Fatal error: insufficient security". Downgrading NSS to 3.26 let's Thunderbird speak to Guam again. Guam version: guam-0.8.3-1.2.el7.kolab_16.x86_64

Details

Ticket Type
Task

Event Timeline

tobru raised the priority of this task from 60 to Unbreak Now!.Oct 24 2016, 5:20 PM
tobru created this task.
tobru added projects: Guam, Restricted Project.

fwiw:
This can be reproduced on a fully-updated ArchLinux or Fedora 24. Additional we have some reports from IOS 10 users.

Confirmed on Fedora 23:
sudo rpm -q nss thunderbird
nss-3.27.0-1.1.fc23.x86_64
nss-3.27.0-1.1.fc23.i686
thunderbird-45.2.0-1.fc23.x86_64

vanmeeuwen claimed this task.
vanmeeuwen removed projects: Restricted Project, Guam.
vanmeeuwen moved this task from Backlog to Reviewed on the Bug Reports board.
vanmeeuwen subscribed.

This issue has escalated to another ticket known as Bifrost#T10720 for enterprise-level support.

It seems to impact all consumers of NSS 3.27, 3.27.0 (some packaged versions of 3.27 are represented as 3.27.0), as well as 3.27.1.

It seems to be caused by a neglect of downstream packagers to include all of as many as two flags that seem to have confused upstream as well, which is understandable.

I cannot reproduce the issue when I resolve the confusion unambiguously, indicating the root cause is with your favorite distribution's vendor or support group.

At your vendor or Contributors Anonymous support group, please ask the maintainers of NSS ever so kindly, to void the ambiguity around setting environment variables NSS_DISABLE_TLS_1_3=1 and NSS_ENABLE_TLS_1_3=0. Please point them upstream for a clarification about the ambiguity, most notably release notes they should have already read and as well as one particular comment in the ticket referred to.

That said, this issue is not an issue for the Kolab product, but rather an upstream as well as distributor problem.

vanmeeuwen changed the task status from Invalid to Resolved.Nov 4 2016, 10:39 PM
vanmeeuwen moved this task from Reviewed to Maintenance on the Bug Reports board.

Despite the harsh tone of the previous comment, I'm going to have to let you have an update. All gratitude is to go to the original reporter, @tobru, for allowing me to have an excuse to spend as much time and resources on this as I did ultimately have had to.