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

[Arran Cudbard-Bell]

> On Jun 8, 2021, at 6:48 AM, Hubert Kario <hkario at redhat.com> wrote:
> 
> On Monday, 7 June 2021 21:01:04 CEST, 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.
> 
> Note that many tools are able to produce a keyfile that wireshark can use
> to decrypt the encrypted parts of handshake and exchanged data too.
> 
> Look for SSLKEYLOGFILE in https://wiki.wireshark.org/TLS
> 
> It's supported in clients like Firefox and curl, as well as in servers,
> like httpd: https://github.com/apache/httpd/pull/74

That's very interesting, I'll look into providing support for keylog files in FreeRADIUS as well.

PR for enabling ssl-trace by default is open here: https://github.com/openssl/openssl/pull/15665

-Arran
-------------- 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/20210608/b9e18ce2/attachment.sig>