Compression Methods Operational Considerations

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