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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On Jun 8, 2021, at 6:48 AM, Hubert Kario <hkario@xxxxxxxxxx> 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

Attachment: signature.asc
Description: Message signed with OpenPGP


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux