26
3.6 Session Resumption
During the initial handshake between the client and server, the server generates a session identifier ID and passes this value to the client during the handshake. Both the server
and client store the session ID along with the keying material and cipher suite after completion of the handshake for later use. If the server is willing to resume a session at
the request of a client, the server responds with the original session ID and cipher suite at the start of the handshake. In the event that the server is unwilling to resume the session,
the server generates and responds with a new session ID. Typical server implementations are agreeable to resuming a previous session. This is a
secure mode of operation, as the master secret is known only to the client and server, and is coupled with the initial client authentication, if client authentication was required.
However, if there is a requirement to authenticate each client as it initiates a connection
session, the server shall be configured to ignore requests to resume a session, and
generate a new session ID, which forces the entire handshake procedure including client authentication to proceed.
3.7 Compression Methods
The use of compression may enable attackers to perform attacks using compression- based side channels. Because of this, only the null compression method, which disables
TLS compression, should be used. If compression is used, the methods defined in
[ RFC3749
] shall be used. If the client population served is known to support the
compression method in [ RFC3943
], that method may be used instead. Other
compression methods shall not be used. Compression method recommendations are
based on the TLS standards. Limitations are recommended to ensure interoperability.
3.8 Operational Considerations
The sections above specify TLS-specific functionality. This functionality is necessary, but is not sufficient, to achieve security in an operational environment.
Federal agencies shall ensure that TLS servers include appropriate network security
protections as specified in other NIST guidelines, such as [ SP800-53
].
The server shall operate on a secure operating system
22
. Where the server relies on a
FIPS 140 Level 1 cryptographic module, the software and private key shall be protected
using the operating system identification, authentication and access control mechanisms. In some highly sensitive applications, server private keys may require protection using a
FIPS 140 Level 2 or higher hardware cryptographic module. The server and associated platform shall be kept up-to-date in terms of security patches.
This is critical to various aspects of security, including the black list of certificates pushed by the product vendors. The black list of certificates is useful when an upstream
CA certificate or client certificate is declared to be invalid or not operating with
22 A secure operating system contains and uses the following features: operating system protection from applications
and processes; operating system mediated isolation among applications and processes; user identification and authentication; access control based on authenticated user identity, and event log of security relevant activities.
27 appropriate security measures, and the server does not perform revocation checking, does
not have access to the latest revocation information, or the certificate has not been revoked.
3.9 Server Recommendations