What's the rationale behind ssl-trace not being built by default?
matt at openssl.org
Mon Jun 7 21:57:47 UTC 2021
On 07/06/2021 20:01, Arran Cudbard-Bell wrote:
> The tables to convert extension IDs and compression methods to humanly readable names are not available outside ssl/t1_trace.c.
> SSL_trace() itself produces reams of helpful information as handshakes progress, and is particularly useful for dealing with encrypted handshakes, where wireshark et al don't provide useful output.
> What is the rationale for ssl-trace to be disabled by default? Was it purely to keep binary sizes down, or was there a security aspect to the decision?
Its a really good question and I've often wondered the same thing. The
decision was made before my time. I suspect it was about keeping binary
sizes down, but I can't imagine it would make that much difference. I
have previously considered turning it on by default but never quite got
around to it.
More information about the openssl-users