Skip to content

tls: add missing stats for signature algorithms. #14703

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ggreenway merged 1 commit into from
Jan 14, 2021
Merged

tls: add missing stats for signature algorithms. #14703

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 32 additions & 11 deletions source/extensions/transport_sockets/tls/context_impl.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -464,30 +464,51 @@ ContextImpl::ContextImpl(Stats::Scope& scope, const Envoy::Ssl::ContextConfig& c
parsed_alpn_protocols_ = parseAlpnProtocols(config.alpnProtocols());

// Use the SSL library to iterate over the configured ciphers.
//
// Note that if a negotiated cipher suite is outside of this set, we'll issue an ENVOY_BUG.
for (TlsContext& tls_context : tls_contexts_) {
for (const SSL_CIPHER* cipher : SSL_CTX_get_ciphers(tls_context.ssl_ctx_.get())) {
stat_name_set_->rememberBuiltin(SSL_CIPHER_get_name(cipher));
}
}

// Add hardcoded cipher suites from the TLS 1.3 spec:
// Add supported cipher suites from the TLS 1.3 spec:
// https://tools.ietf.org/html/rfc8446#appendix-B.4
// AES-CCM cipher suites are removed (no BoringSSL support).
//
// Note that if a negotiated cipher suite is outside of this set, we'll issue an ENVOY_BUG.
stat_name_set_->rememberBuiltins(
{"TLS_AES_128_GCM_SHA256", "TLS_AES_256_GCM_SHA384", "TLS_CHACHA20_POLY1305_SHA256"});

// Curves from
// https://github.com/google/boringssl/blob/f4d8b969200f1ee2dd872ffb85802e6a0976afe7/ssl/ssl_key_share.cc#L384
// All supported curves. Source:
// https://github.com/google/boringssl/blob/3743aafdacff2f7b083615a043a37101f740fa53/ssl/ssl_key_share.cc#L302-L309
//
// Note that if a curve is configured outside this set, we'll issue an ENVOY_BUG so
// it will hopefully be caught.
stat_name_set_->rememberBuiltins(
{"P-224", "P-256", "P-384", "P-521", "X25519", "CECPQ2", "CECPQ2b"});
// Note that if a negotiated curve is outside of this set, we'll issue an ENVOY_BUG.
stat_name_set_->rememberBuiltins({"P-224", "P-256", "P-384", "P-521", "X25519", "CECPQ2"});

// Algorithms
stat_name_set_->rememberBuiltins({"ecdsa_secp256r1_sha256", "rsa_pss_rsae_sha256"});

// Versions
// All supported signature algorithms. Source:
// https://github.com/google/boringssl/blob/3743aafdacff2f7b083615a043a37101f740fa53/ssl/ssl_privkey.cc#L436-L453
//
// Note that if a negotiated algorithm is outside of this set, we'll issue an ENVOY_BUG.
stat_name_set_->rememberBuiltins({
Copy link
Contributor

@jmarantz jmarantz Jan 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These weren't showing up in our test-suites; why would we start seeing those in calls to incCounter?

Should we add tests that would fail if these were missing? What I mean by this is not directly calling incCounter with these from the unit test, but somehow induce the code to call incCounter with one of these from some kind of higher level tests.

Copy link
Contributor Author

@PiotrSikora PiotrSikora Jan 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These weren't showing up in our test-suites; why would we start seeing those in calls to incCounter?

I didn't encounter any issues running tests (tests don't exercise all possible values), but in the real world.

Should we add tests that would fail if these were missing? What I mean by this is not directly calling incCounter with these from the unit test, but somehow induce the code to call incCounter with one of these from some kind of higher level tests.

I'm not sure what are you trying to achieve here? Get coverage for all possible protocol versions, cipher suites, curves and signature algorithms?

Copy link
Contributor

@jmarantz jmarantz Jan 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just wondering what was different about the traffic that woke up these signatures being counted, and whether we should have tests for that.

I would feel different if the implementation called for N signatures and we only had symbolized N-1, but we didn't have any of them :)

Copy link
Contributor Author

@PiotrSikora PiotrSikora Jan 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just a noisy diff, we already had 2 algorithms (ecdsa_secp256r1_sha256 and rsa_pss_rsae_sha256) that were negotiated during tests.

"rsa_pkcs1_md5_sha1",
"rsa_pkcs1_sha1",
"rsa_pkcs1_sha256",
"rsa_pkcs1_sha384",
"rsa_pkcs1_sha512",
"ecdsa_sha1",
"ecdsa_secp256r1_sha256",
"ecdsa_secp384r1_sha384",
"ecdsa_secp521r1_sha512",
"rsa_pss_rsae_sha256",
"rsa_pss_rsae_sha384",
"rsa_pss_rsae_sha512",
"ed25519",
});

// All supported protocol versions.
//
// Note that if a negotiated version is outside of this set, we'll issue an ENVOY_BUG.
stat_name_set_->rememberBuiltins({"TLSv1", "TLSv1.1", "TLSv1.2", "TLSv1.3"});
}

Expand Down