TLS: Split client/server cipher/curve defaults

[skippy]

hey folks,

this follows up a conversation from the envy-users google group.

I ran into an issue trying to use EC 384 certs for SSL when using the lyft/envoy:1.3.0 docker image on kubernetes. vault is used to produce the certs (the vault role config files are included as a reference)

I run a group of envoy_edge servers that communicate to an envoy attached to a service (aka a sidecar). When the SSL cert/key used to communicate from the edge -> service is an EC 384 certificate, the edge returns upstream connect error or disconnect/reset before headers. No exceptions are displayed in the logs, even in trace mode.

When the exact same configurations are used except the underlying SSL cert/key is EC 256 or RSA 2048, it works as expected (the edge passes it to one of he nodes in the cluster, which successfully returns a response.

It was suggested on the emailing list to start by providing examples of passing and failing certs. I've also attached the edge and service envoy config file. (The .txt suffix was added to allow it to be attached to a PR). Let me know if you need additional information.

thanks!

envoy_edge_ec256.ca.txt
envoy_edge_ec256.crt.txt
envoy_edge_ec256.key.txt
envoy_edge_ec384.ca.txt
envoy_edge_ec384.crt.txt
envoy_edge_ec384.key.txt
envoy_edge.json.txt
envoy_service_ec256.ca.txt
envoy_service_ec256.crt.txt
envoy_service_ec256.key.txt
envoy_service_ec384.ca.txt
envoy_service_ec384.crt.txt
envoy_service_ec384.key.txt
envoy_service.json.txt
vault_pki_policy_ec256.json.txt
vault_pki_policy_ec384.json.txt

[mattklein123]

I think we have gotten to the bottom of this in the linked email thread.

@PiotrSikora I will leave this open for a bit in case we want to use it to change any defaults.

[skippy]

hey @mattklein123 and @PiotrSikora

The suggestions in the email chain worked btw. Thanks for that!! I never would have figured that out.

As an end-user, it would help a ton if there was debug or trace level logging of the tls/ssl connections. It is telling that not only did I miss what the configuration tweak, but that most folks on the development side did as well. tls can get complex really quickly!

In an "ideal" world, an end user would see:

• error msg if ssl cannot work; with which step failed and a msg as to why
• debug: show start (using which protocol, cipher suite, etc) and success/failure of ssl connection
• trace: show each individual step of ssl connection (like curl -vvv)

I have NO idea what is possible and what sort of visibility BoringSSL gives to the underlying steps.

BUT, with all that said, thank you for your help!

[mattklein123]

debug/trace messages are compiled out of release builds currently. See #1088

[davidben]

On the BoringSSL side the things, I believe the error would have been surfaced out of the client code SSL_R_BAD_ECC_CERT in the funny OpenSSL error queue thingy.

[mattklein123]

Yeah the error would have printed by default on debug level now that #1088 has been merged. I'm going to change this issue to track an enhancement to fix the client side cipher/curve defaults.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[mattklein123]

@PiotrSikora you just fixed this right?

[PiotrSikora]

@mattklein123 yes, in theory, since defaults are now defined separately in the code, but they are still the same in practice.

Note that this issue is really about adding P-384 to the default curves used for outgoing connections, but seeing that we outright banned P-384 in ECDSA certificates (#5224), I'm not sure if adding it to the default curves used for session key agreement makes a lot of sense now...

Also, this was the only complaint about it in Envoy history (AFAIK), so we should probably just close it.

[mattklein123]

OK closing