If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

TLS and secure cipher suites disabled by default

RESOLVED INVALID

Status

NSS
Libraries
RESOLVED INVALID
5 years ago
5 years ago

People

(Reporter: Florian Weimer, Unassigned)

Tracking

3.13.6
x86_64
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 686022 [details]
TLS-Client-NSS.c

The attached example code fails with:

error: SSL_ForceHandshake error -12268: SSL_ERROR_SSL_DISABLED

In order to avoid this error, it is necessary to call NSS_SetDomesticPolicy and SSL_CipherPrefSet.  NSS should enable the requires ciphers by default (and disable insecure ciphers), so that code which uses NSS does not have to hard-code an acceptable set of ciphers.
(Reporter)

Comment 1

5 years ago
3.14 appears to be affected as well.
(Reporter)

Comment 2

5 years ago
Created attachment 710626 [details] [diff] [review]
Untested patch updating header file

It turns out that calling NSS_SetExportPolicy does most of what I want.  The description in the header file is just flat-out wrong.  There is never a reason to call NSS_SetDomesticPolicy.

I still think TLS and strong ciphers should work bey default, so that neither function has to be called.  The both these functions could be NOPs.  Eventually, NSS_SetExportPolicy could be deprecated as well.  (At the moment, you'll want to call it for compatibility with older NSS versions.)

Please double-check this carefully, I might be missing something important.  The overall situation is pretty bizarre from my point of view.

Updated

5 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

5 years ago
Comment on attachment 710626 [details] [diff] [review]
Untested patch updating header file

Thank you for the patch. The new comments are incorrect.
I think the problem is elsewhere.

In recent versions of NSS, NSS_SetExportPolicy simply
calls NSS_SetDomesticPolicy:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/sslsock.c&rev=1.99&mark=1313,1327,1329#1312

So if one works for you, the other should also work.
Attachment #710626 - Flags: review-

Comment 4

5 years ago
I believe this bug is invalid. But I agree we should make it easier (or more obvious) for new applications to get started, by offering a default policy. I proposed that in bug 842307
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
(Reporter)

Comment 5

5 years ago
(In reply to Florian Weimer from comment #1)
> 3.14 appears to be affected as well.

I take that back.  In 3.14, it is sufficient to call NSS_SetDomesticPolicy.  I double-checked, and in our version of 3.13.1, it was not, so the bug report isn't entirely invalid.  But what matters is that it was fixed.
You need to log in before you can comment on or make changes to this bug.