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

Matt



[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