cipher_suite_name in net_tls_connection can show incorrect values when using TLS 1.3

[ameyer117]

Describe the bug The net_tls_connection connection table can possibly have incorrect values for cipher_suite_name when connecting via TLS 1.3. Looking at the code, it is returning the requested cipher suite, while the docs say it is the "Negotiated cipher suite". This would be true up until this change made by the Go team for TLS 1.3 (and remains true for TLS 1.2 and below). This causes the net plugin to report that ciphers such as TLS_CHACHA20_POLY1305_SHA256 were able to complete a handshake, when in fact they were not, and Go automatically negotiated another cipher that the server supports such as TLS_AES_128_GCM_SHA256 to make the connection. This is largely a big problem for compliance environments where reports are needed for compliant TLS ciphers for production web servers.

Steampipe version (steampipe -v) v0.23.2

Plugin version (steampipe plugin list) v0.12.0

To reproduce Place a Linux web server with openssl in FIPS mode and run a simple Nginx server. It will not support TLS_CHACHA20_POLY1305_SHA256 as its not FIPS validated. This can be verified with openssl ciphers -v

Run the steampipe query

select
  address,
  version,
  cipher_suite_name,
  handshake_completed
from
  net_tls_connection
where
  address = 'YOUR_NGINX_SERVER:443'
  and handshake_completed;

and notice results such as:

  +-----------------+----------+---------------------------------------+-----------------+---------------------+----------------+
| address         | version  | cipher_suite_name                     | cipher_suite_id | handshake_completed | alpn_supported |
+-----------------+----------+---------------------------------------+-----------------+---------------------+----------------+
| 10.0.84.132:443 | TLS v1.3 | TLS_AES_256_GCM_SHA384                | 0x1302          | true                | true           |
| 10.0.84.132:443 | TLS v1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | 0xc02f          | true                | true           |
| 10.0.84.132:443 | TLS v1.3 | TLS_AES_128_GCM_SHA256                | 0x1301          | true                | true           |
| 10.0.84.132:443 | TLS v1.3 | TLS_CHACHA20_POLY1305_SHA256          | 0x1303          | true                | true           |
| 10.0.84.132:443 | TLS v1.2 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | 0xc030          | true                | true           |
+-----------------+----------+---------------------------------------+-----------------+---------------------+----------------+

Where steampipe is claiming it connected to that server which doesn't support TLS_CHACHA20_POLY1305_SHA256 using the TLS_CHACHA20_POLY1305_SHA256 cipher.

Expected behavior Either replace the cipher_suite_name and ciper_suite_id with the real negotiated cipher instead of the requested one or add a new column for a negotiated cipher to distinguish the difference.

Additional context Helpful Go test code for this issue. https://go.dev/blog/tls-cipher-suites https://github.com/golang/go/issues/29349

[ameyer117]

My personal opinion is it would be best to add new columns, and just change the documentation for the old column to be "Requested cipher suite" instead of "Negotiated cipher suite"

[ameyer117]

@ParthaI - this is still an issue and causes confusion in "higher" U.S. compliance based environments. Just wanted to make sure this is still on your radar. Thank you!

[ParthaI]

Apologies, @ameyer117, I haven’t had a chance to work on this issue yet. However, it’s on my radar.