Detections
Analytics

6.10 Ensure Weak SSL/TLS Ciphers Are Disabled

Information

The PostgreSQL ssl_ciphers directive specifies which Cipher Suites are allowed in the negotiation with the client.

In cryptography, perfect forward secrecy (PFS), also known as forward secrecy (FS), is a feature of specific key exchange protocols that give assurance that the session keys will not be compromised even if the private key of the server is compromised. For instance, RSA does not provide PFS, while the ECDHE (Elliptic-Curve Diffie-Hellman Ephemeral) and DHE (Diffie-Hellman Ephemeral) provides PFS.

ECDHE is the stronger protocol and should be preferred, while DHE may be allowed for greater compatibility with older clients. Only Cipher Suites with either the ECDHE or the DHE key exchange are allowed.

Rationale:

The SSL/TLS protocols support a large number of Cipher Suites including many weak and medium strength algorithms that are subject to man-in-the middle attacks and information disclosure. Some implementations even support the NULL Cipher Suite which allows a TLS connection without any cryptographic protection. Therefore, it is critical to ensure the configuration only allows strong algorithms greater than or equal to 128-bit to be negotiated with the client. Stronger 256-bit algorithms should be allowed and preferred.

Furthermore, during the TLS handshake, after the initial Client Hello and Server Hello, there is a pre-master secret generated, which is used to generate the master secret, and in turn generates the session key. When using protocols that do not provide forward secrecy, such as RSA, the pre-master secret is encrypted by the client with the server's public key and sent over the network. However, with protocols such as ECDHE (Elliptic-Curve Diffie-Hellman Ephemeral) the pre-master secret is not sent over the wire, even in encrypted format. The key exchange arrives at the shared secret in the clear using ephemeral keys that are not stored or used again. With forward secrecy, each session has a unique key exchange, so that future sessions are protected.

Note This recommendation is primarily targeted at those installs that cannot run in FIPS-mode, or need to further refine the allowable cipher list.

Solution

Add or modify the ssl_ciphers directive to the following value in the PostgreSQL configuration file (postgresql.conf):

ssl_ciphers = 'TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_AES_128_CCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,ECDHE-ECDSA-AES256-CCM,ECDHE-ECDSA-AES128-CCM,DHE-RSA-AES256-CCM,DHE-RSA-AES128-CCM,ECDHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES256-GCM-SHA384,ECDHE-ECDSA-AES128-GCM-SHA256,DHE-DSS-AES256-GCM-SHA384,DHE-DSS-AES128-GCM-SHA256,DHE-RSA-AES256-GCM-SHA384,DHE-RSA-AES128-GCM-SHA256,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-RSA-CHACHA20-POLY1305,DHE-RSA-CHACHA20-POLY1305'

See Also

https://workbench.cisecurity.org/benchmarks/17003

Item Details

Category: ACCESS CONTROL, IDENTIFICATION AND AUTHENTICATION, SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|AC-17(2), 800-53|IA-5, 800-53|IA-5(1), 800-53|SC-8, 800-53|SC-8(1)

Plugin: Unix

Control ID: 53b1e0449e2fd1ddb882673f5011eefdcf6a7ca910b007743c719ffb71c83cd3