What's the rationale behind ssl-trace not being built by default?

Arran Cudbard-Bell a.cudbardb at freeradius.org
Mon Jun 7 19:01:04 UTC 2021

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210607/3da13bbc/attachment-0001.sig>

More information about the openssl-users mailing list