4 ms·
My biggest gripe is the inability, or my lack of knowledge on how, to enable observability (metrics and events) on the failure cases. Maybe it is possible with
by spockz 6y ago
My biggest gripe is the inability, or my lack of knowledge on how, to enable observability (metrics and events) on the failure cases. Maybe it is possible with recompiling the code but this won’t help if OpenSSL comes packaged in something like envoy.
I want to be able to see metrics of how often which rejection occurred. Preferably even security events for each failed tls connection including peer identity, and the failure reason.
(I’m silently rooting that someone will tell me I’m wrong and shows that it is possible to do the above...)
- asveikau 6y agoIf you had something with a lot of traffic logging TLS issues I wonder if you would see noise from packets corrupted by hardware that were not caught by the TCP checksum. That or some low, interesting number of users with very badly misconfigured peers, where it's not your responsibility to fix. I can't recall the exact details. But i remember once logging crypto failures on a high usage app, and it seemed noisy for something like that. Similarly to collecting logs for i/o failures in the field, if you have legit bugs they are often drowned out by issues caused by bad disks.
- spockz 6y agoOk. From our basic metrics on failed/successful tls connection established, I can conclude we only are dealing with incorrectly configured clients and not from random glitches. Peers keep connecting properly after they have figured out how the first time. I would expect the events to be rich enough In information to distinguish corruption from really sending incompatible parameters/certs vs checksum failures.
- davinci26 6y agoEnvoy comes with ssl support and it uses the google variant of openssl (boringssl).
- spockz 6y agoAh indeed, I was put on the wrong foot because the error messages are similar. But it has the same downside of being hard to troubleshoot.