Bug 669446 - Default encryption strength dropped in switch to using NSS
Summary: Default encryption strength dropped in switch to using NSS
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openldap
Version: 14
Hardware: Unspecified
OS: Unspecified
low
high
Target Milestone: ---
Assignee: Jan Vcelak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 669845
TreeView+ depends on / blocked
 
Reported: 2011-01-13 17:29 UTC by Tyson Whitehead
Modified: 2013-03-04 01:28 UTC (History)
3 users (show)

(edit)
Clone Of:
: 669845 (view as bug list)
(edit)
Last Closed: 2011-09-25 03:47:13 UTC


Attachments (Terms of Use)

Description Tyson Whitehead 2011-01-13 17:29:18 UTC
Description of problem:

Switching to using NSS for TLS/SSL has changed the default, priority-sorted, list-of-cipher-suites-supported transmitted by clients.  The new list is

00 00 04 - SSL3_CK_RSA_RC4_128_MD5
00 fe ff - -- not sure what this is --
00 00 0a - SSL3_CK_RSA_DES_192_CBC3_SHA
00 fe fe - -- not sure what this is --
00 00 09 - SSL3_CK_RSA_DES_64_CBC_SHA
00 00 64 - TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_SHA  --
00 00 62 - TLS1_CK_RSA_EXPORT1024_WITH_DES_CBC_SHA --
00 00 03 - SSL3_CK_RSA_RC4_40_MD5
00 00 06 - SSL3_CK_RSA_RC2_40_MD5
00 00 ff - SSL3_CK_SCSV

The strongest and most preferred cipher suite on this list RC4/MD5.  It is at best a medium grade suite.  Compare this to the old OpenSSL list

00 00 39 - TLS1_CK_DHE_RSA_WITH_AES_256_SHA
00 00 38 - TLS1_CK_DHE_DSS_WITH_AES_256_SHA
00 00 35 - TLS1_CK_RSA_WITH_AES_256_SHA
00 00 88 - TLS1_CK_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
00 00 87 - TLS1_CK_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
00 00 84 - TLS1_CK_RSA_WITH_CAMELLIA_256_CBC_SHA
00 00 16 - SSL3_CK_EDH_RSA_DES_192_CBC3_SHA
00 00 13 - SSL3_CK_EDH_DSS_DES_192_CBC3_SHA
00 00 0a - SSL3_CK_RSA_DES_192_CBC3_SHA
07 00 c0 - SSL2_CK_DES_192_EDE3_CBC_WITH_MD5
00 00 33 - TLS1_CK_DHE_RSA_WITH_AES_128_SHA
00 00 32 - TLS1_CK_DHE_DSS_WITH_AES_128_SHA
00 00 2f - TLS1_CK_RSA_WITH_AES_128_SHA
00 00 9a - TLS1_CK_DHE_RSA_WITH_SEED_SHA
00 00 99 - TLS1_CK_DHE_DSS_WITH_SEED_SHA
00 00 96 - TLS1_CK_RSA_WITH_SEED_SHA
00 00 45 - TLS1_CK_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
00 00 44 - TLS1_CK_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
00 00 41 - TLS1_CK_RSA_WITH_CAMELLIA_128_CBC_SHA
03 00 80 - SSL2_CK_RC2_128_CBC_WITH_MD5
00 00 05 - SSL3_CK_RSA_RC4_128_SHA
00 00 04 - SSL3_CK_RSA_RC4_128_MD5
01 00 80 - SSL2_CK_RC4_128_WITH_MD5
00 00 15 - SSL3_CK_EDH_RSA_DES_64_CBC_SHA
00 00 12 - SSL3_CK_EDH_DSS_DES_64_CBC_SHA
00 00 09 - SSL3_CK_RSA_DES_64_CBC_SHA
06 00 40 - SSL_OP_MSIE_SSLV2_RSA_PADDING
00 00 14 - SSL3_CK_EDH_RSA_DES_40_CBC_SHA
00 00 11 - SSL3_CK_EDH_DSS_DES_40_CBC_SHA
00 00 08 - SSL3_CK_RSA_DES_40_CBC_SHA
00 00 06 - SSL3_CK_RSA_RC2_40_MD5
04 00 80 - SSL2_CK_RC2_128_CBC_EXPORT40_WITH_MD5
00 00 03 - SSL3_CK_RSA_RC4_40_MD5
02 00 80 - SSL2_CK_RC4_128_EXPORT40_WITH_MD5

which contains (and prefers) several high grade cipher suites such as AES256/SHA (RC4/MD5, the best default NSS cipher suite, is twenty first on this list).

The net effect of this is everyone running with the defaults will just have had their encryption downgraded for them by this update.  We only happened to discover what was going on after much pain because our servers are configured to not make certain records available unless a high grade ciphers are being used.

Version-Release number of selected component (if applicable): 2.4.23

How reproducible: always

Steps to Reproduce:

1. in one terminal run "openssl s_server -nocert -port 10000 -msg"
2. in another terminal run "ldapsearch -H ldaps://localhost:10000"
3. decode the SSL 2.0 CLIENT_HELLO message in the first terminal according to

http://www.mozilla.org/projects/security/pki/nss/ssl/draft02.html

and you will get the above lists of cipher suites (Fedora 14 boxes will give you the first list, older Fedora versions will give you the second list).

Actual results:  The best cipher suite in the default NSS client list of supported ciphers is at best a medium grade cipher suite.

Expected results:  The default NSS client list of supported ciphers should contain at least one high quality cipher suite, and this cipher suite should appear first as the preferred cipher suite, as was the case with OpenSSL.

Additional info:

Note that I'm not reporting that I can't make the system work.  Indeed, specifying "TLS_CIPHER_SUITE HIGH" in ~/.ldaprc gives the following list

00 00 35 - TLS1_CK_RSA_WITH_AES_256_SHA
00 00 2f - TLS1_CK_RSA_WITH_AES_128_SHA
00 00 0a - SSL3_CK_RSA_DES_192_CBC3_SHA
00 00 ff - SSL3_CK_SCSV

which is sufficient for our purposes.  What I'm reporting is that the default ciphers were downgrade, and I suspect most Fedora 14 users will be blissfully unaware of this.  Perhaps this should be filed against NSS.

Comment 1 Rich Megginson 2011-01-13 18:25:56 UTC
So if openldap made the default cipher suite list TLS_CIPHER_SUITE HIGH, would that solve the problem, and make openldap with moznss work exactly like openldap with openssl?

Comment 2 Tyson Whitehead 2011-01-14 04:05:37 UTC
That would likely be better than the default of only use medium and low grade cipher suites.  It still wouldn't be technically equivalent though as then the client would only use high grade cipher suites.

I had a look at the OpenSSL LDAP library code (tls_m.c) and it looks like the best you can do without editing the code is to make ALL the default.  This gives a client list of

00 00 35 - TLS1_CK_RSA_WITH_AES_256_SHA
00 00 04 - SSL3_CK_RSA_RC4_128_MD5
00 00 05 - SSL3_CK_RSA_RC4_128_SHA
00 00 2f - TLS1_CK_RSA_WITH_AES_128_SHA
00 00 0a - SSL3_CK_RSA_DES_192_CBC3_SHA
00 00 09 - SSL3_CK_RSA_DES_64_CBC_SHA
00 00 64 - TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_SHA
00 00 62 - TLS1_CK_RSA_EXPORT1024_WITH_DES_CBC_SHA
00 00 03 - SSL3_CK_RSA_RC4_40_MD5
00 00 06 - SSL3_CK_RSA_RC2_40_MD5
00 00 ff - SSL3_CK_SCSV

which, while not as extensive as the OpenSSL one, contains a reasonable subset of it and prefers the strongest suites.

Cheers!  -Tyson

PS:  From looking at the code, it seems this is not a limitation of NSS but rather the OpenLDAP NSS interface (tls_m.c), which uses a hard coded list, compared to the OpenSSL interface (tls_o.c), which queries the library.

Comment 3 Rich Megginson 2011-01-14 22:12:57 UTC
(In reply to comment #2)
> That would likely be better than the default of only use medium and low grade
> cipher suites.  It still wouldn't be technically equivalent though as then the
> client would only use high grade cipher suites.
> 
> I had a look at the OpenSSL LDAP library code (tls_m.c) and it looks like the
> best you can do without editing the code is to make ALL the default.  This
> gives a client list of
> 
> 00 00 35 - TLS1_CK_RSA_WITH_AES_256_SHA
> 00 00 04 - SSL3_CK_RSA_RC4_128_MD5
> 00 00 05 - SSL3_CK_RSA_RC4_128_SHA
> 00 00 2f - TLS1_CK_RSA_WITH_AES_128_SHA
> 00 00 0a - SSL3_CK_RSA_DES_192_CBC3_SHA
> 00 00 09 - SSL3_CK_RSA_DES_64_CBC_SHA
> 00 00 64 - TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_SHA
> 00 00 62 - TLS1_CK_RSA_EXPORT1024_WITH_DES_CBC_SHA
> 00 00 03 - SSL3_CK_RSA_RC4_40_MD5
> 00 00 06 - SSL3_CK_RSA_RC2_40_MD5
> 00 00 ff - SSL3_CK_SCSV

I've made two changes:
1) if no cipher suite is specified, set it to "DEFAULT"
2) add more cipher suites to the list of default cipher suites

When I do this, I get the list specified above when running your commands.

> which, while not as extensive as the OpenSSL one, contains a reasonable subset
> of it and prefers the strongest suites.
> 
> Cheers!  -Tyson
> 
> PS:  From looking at the code, it seems this is not a limitation of NSS but
> rather the OpenLDAP NSS interface (tls_m.c), which uses a hard coded list,
> compared to the OpenSSL interface (tls_o.c), which queries the library.

We tried to keep the openldap tls settings exactly the same.  For the cipher suite specification, openldap uses the strings used internally by openssl - that is, it just passes the string directly to SSL_CTX_set_cipher_list().  NSS doesn't support those strings, so we have to manually convert the cipher spec strings.  We chose the most common and required cipher suites.  We can add more if needed.

Comment 4 Rich Megginson 2011-01-15 00:19:58 UTC
ITS and patch submitted upstream: http://www.openldap.org/its/index.cgi?findid=6790

Comment 5 Jan Vcelak 2011-01-20 17:25:40 UTC
Fixed in openldap-2.4.23-6.fc14

Comment 6 Fedora Update System 2011-01-20 17:27:10 UTC
openldap-2.4.23-6.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/openldap-2.4.23-6.fc14

Comment 7 Fedora Update System 2011-01-21 23:02:00 UTC
openldap-2.4.23-6.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update openldap'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/openldap-2.4.23-6.fc14

Comment 8 Fedora Update System 2011-01-25 13:35:11 UTC
openldap-2.4.23-7.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/openldap-2.4.23-7.fc14

Comment 9 Fedora Update System 2011-02-02 12:43:21 UTC
openldap-2.4.23-8.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/openldap-2.4.23-8.fc14

Comment 10 Fedora Update System 2011-03-01 12:42:04 UTC
Package openldap-2.4.21-12.fc13:
* should fix your issue,
* was pushed to the Fedora 13 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openldap-2.4.21-12.fc13'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/openldap-2.4.21-12.fc13
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2011-03-01 12:42:50 UTC
Package openldap-2.4.23-9.fc14:
* should fix your issue,
* was pushed to the Fedora 14 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openldap-2.4.23-9.fc14'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/openldap-2.4.23-9.fc14
then log in and leave karma (feedback).

Comment 12 Fedora Update System 2011-03-19 00:20:56 UTC
openldap-2.4.23-10.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/openldap-2.4.23-10.fc14

Comment 13 Fedora Update System 2011-09-25 03:46:31 UTC
openldap-2.4.23-10.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.