> On Jun 7, 2021, at 4:57 PM, Matt Caswell <matt@xxxxxxxxxxx> wrote: > > > > 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. If you don't have any objections I could submit a PR to enable it by default? I'd image that the platforms that'd care about a few extra kb are in the minority, and it makes such a huge difference having SSL_trace() when trying to debug TLS 1.3 issues. -Arran
Attachment:
signature.asc
Description: Message signed with OpenPGP
