Tanzu Telemetry Centralizer allows for weak TLS ciphers

Products

• VMware Tanzu Platform Core

Issue/Introduction

Attempting to connect to telemetry-centralizer over port 24224 using a weak TLS cipher results in a successful connection.

Example:

openssl s_client -connect localhost:24224 -cipher CAMELLIA256-SHA256

CONNECTED(00000003)

New, TLSv1.2, Cipher is CAMELLIA256-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : CAMELLIA256-SHA256

This issue impacts Telemetry tile 2.4.4 and lower versions.

Cause

The telemetry-centralizer runs Fluentd, which listens on port 24224 with TLS enabled. The Fluentd transport configuration had no explicit cipher suite restriction, so it fell back to Fluentd's default: ALL:!aNULL:!eNULL:!SSLv2. This allows use of dozens of weak ciphers.

Resolution

This issue will be fixed in an upcoming release of Telemetry for Tanzu tile. This article will be updated once released.

Fix: Two config template changes in the telemetry BOSH release:

1. Centralizer (Fluentd server, port 24224): Added min_version TLS1_2 and ciphers ECDHE+AESGCM:!aNULL:!eNULL:!SSLv2 to the <transport tls> block.
2. Agent (Fluent Bit client, every VM): Added tls.min_version TLSv1.2 and tls.ciphers ECDHE+AESGCM to the forward output section.

After the fix, the only TLS 1.2 cipher suites accepted are:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS 1.3 is also supported (all TLS 1.3 ciphers are inherently strong).

This eliminates all weak ciphers. The fix is backwards-compatible with existing deployed agents (they already offer ECDHE+AESGCM among their defaults).