Enforce Cipher suites on cluster port 8201

[ryhoo2]

Related to #1193

How to enforce those ciphers also for the cluster_address (default port 8201)? If I set the tls_cipher_suites parameter it works only for the main TCP listener (port 8200) and not the cluster one. With the example listener like this:

listener "tcp" {
address = "0.0.0.0:8200"
cluster_address = "0.0.0.0:8201"
tls_min_version = "tls12"
tls_cert_file = "/certs/server.crt"
tls_key_file = "/certs/server.key"
tls_cipher_suites = "TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
tls_prefer_server_cipher_suites = "true"
}

The ciphers are properly configured only on port 8200, and port 8201 still goes with what seems like to be the Go's default for the TLS v1.2. Here's the output from the TLS scan:

$ ./o-saft.pl --no-sslv2 --no-tlsv13 --ignore-output=https_body --no-dns --enabled --no-header +cipherall 172.28.135.239:8200
172.28.135.239, 8200, SSLv3 (0x0300), no SNI, , ,

172.28.135.239, 8200, TLSv1 (0x0301), no SNI, , ,

172.28.135.239, 8200, TLSv11 (0x0302), no SNI, , ,

172.28.135.239, 8200, TLSv12 (0x0303), no SNI, Server Order, 0x0300009C, AES128-GCM-SHA256 , RSA_WITH_AES_128_GCM_SHA256
172.28.135.239, 8200, TLSv12 (0x0303), no SNI, Server Order, 0x0300009D, AES256-GCM-SHA384 , RSA_WITH_AES_256_GCM_SHA384
172.28.135.239, 8200, TLSv12 (0x0303), no SNI, Server Order, 0x0300C02F, ECDHE-RSA-AES128-GCM-SHA256 , ECDHE_RSA_WITH_AES_128_GCM_SHA256 , (ecdh, (primary) named_curve: ecdh_x25519, 255 bits)

$ ./o-saft.pl --no-sslv2 --no-tlsv13 --ignore-output=https_body --no-dns --enabled --no-header +cipherall 172.28.135.239:8201
172.28.135.239, 8201, SSLv3 (0x0300), no SNI, , ,

172.28.135.239, 8201, TLSv1 (0x0301), no SNI, , ,

172.28.135.239, 8201, TLSv11 (0x0302), no SNI, , ,

172.28.135.239, 8201, TLSv12 (0x0303), no SNI, No Order , 0x0300C009, ECDHE-ECDSA-AES128-SHA , ECDHE_ECDSA_WITH_AES_128_CBC_SHA , (ecdh, (primary) named_curve: ecdh_x25519, 255 bits)
172.28.135.239, 8201, TLSv12 (0x0303), no SNI, No Order , 0x0300C00A, ECDHE-ECDSA-AES256-SHA , ECDHE_ECDSA_WITH_AES_256_CBC_SHA , (ecdh, (primary) named_curve: ecdh_x25519, 255 bits)
172.28.135.239, 8201, TLSv12 (0x0303), no SNI, No Order , 0x0300C02B, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, (ecdh, (primary) named_curve: ecdh_x25519, 255 bits)
172.28.135.239, 8201, TLSv12 (0x0303), no SNI, No Order , 0x0300C02C, ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, (ecdh, (primary) named_curve: ecdh_x25519, 255 bits)
172.28.135.239, 8201, TLSv12 (0x0303), no SNI, No Order , 0x0300CCA9, ECDHE-ECDSA-CHACHA20-POLY1305-SHA256, ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, (ecdh, (primary) named_curve: ecdh_x25519, 255 bits)

[jefferai]

We don't support using custom cipher suites on the cluster port. Since we control both ends of the communication they should always be using a strong cipher. Which cipher suite is being picked that you are finding problematic?

[ryhoo2]

We're building application for Federal Customers and it needs to meet the NIST requirements, especially SP 800-52 specification:
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf
(page 15)

Our Customer requires to limit the list to only those 7:
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
We'd need to remove the ciphers based on SHA1 digest and CHACHA20 encryption - they are not on the approved list.

[jefferai]

I had a suspicion it was due to federal requirements.

[ryhoo2]

Thank You for the quick fix!