Docs/defensive-coding-guide
1
0
Fork 0
Code Issues 3 Pull requests 1 Projects Releases Packages Wiki Activity Actions

TLS Client NSS: Rely on NSS 3.14 cipher suite defaults

Browse source 
Older versions needed application code to actually enable strong
ciphers, but this changed in version 3.14.
This commit is contained in:
Florian Weimer 2013-04-02 17:12:57 +02:00
parent c861995515
commit 04d4055034
4 changed files with 21 additions and 76 deletions
Download patch file Download diff file Expand all files Collapse all files

33
defensive-coding/en-US/Features/TLS.xml
View file

@ -768,8 +768,13 @@
<title>Implementing TLS Clients With NSS</title>
<para>
The following code shows how to implement a simple TLS client
using NSS. Note that the error handling needs replacing
before production use.
using NSS. These instructions apply to NSS version 3.14 and
later. Versions before 3.14 need different initialization
code.
</para>
<para>
Keep in mind that the error handling needs to be improved
before the code can be used in production.
</para>
<para>
Using NSS needs several header files, as shown in
@ -781,17 +786,13 @@
xmlns:xi="http://www.w3.org/2001/XInclude" />
</example>
<para>
Initializing the NSS library is a complex task (<xref
linkend="ex-Defensive_Coding-TLS-NSS-Init"/>). It is not
thread-safe. By default, the library is in export mode, and
all strong ciphers are disabled. Therefore, after creating
the <literal>NSSInitCContext</literal> object, we probe all
the strong ciphers we want to use, and check if at least one
of them is available. If not, we call
<function>NSS_SetDomesticPolicy</function> to switch to
unrestricted policy mode. This function replaces the existing
global cipher suite policy, that is why we avoid calling it
unless absolutely necessary.
Initializing the NSS library is shown in <xref
linkend="ex-Defensive_Coding-TLS-NSS-Init"/>. This
initialization procedure overrides global state. We only call
<function>NSS_SetDomesticPolicy</function> if there are no
strong ciphers available, assuming that it has already been
called otherwise. This avoids overriding the process-wide
cipher suite policy unnecessarily.
</para>
<para>
The simplest way to configured the trusted root certificates
@ -825,11 +826,7 @@
function is de-facto part of the NSS public ABI, so it will
not go away.) Creating the TLS-capable file descriptor
requires a <emphasis>model</emphasis> descriptor, which is
configured with the desired set of protocols and ciphers.
(The <literal>good_ciphers</literal> variable is part of <xref
linkend="ex-Defensive_Coding-TLS-NSS-Init"/>.) We cannot
resort to disabling ciphers not on a whitelist because by
default, the AES cipher suites are disabled. The model
configured with the desired set of protocols. The model
descriptor is not needed anymore after TLS support has been
activated for the existing connection descriptor.
</para>