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

Arran Cudbard-Bell a.cudbardb at freeradius.org
Tue Jun 8 22:00:09 UTC 2021

> 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

-------------- 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>

More information about the openssl-users mailing list