RFC: TLS in rpcaps
tcpdump-workers-9455 at ryanc.org
Mon Jul 4 19:49:34 EDT 2022
I volunteered to add proper TLS certificate validation to libpcap and
tcpdump back in September, and now that I'm funemployed, I've felt
compelled to have a go at it. I've actually got it mostly working.
Before I get too deep into a patchset, I wanted to share a few thoughts,
opinions, and ramblings for feedback:
1) TLS compression support is a foot-bazooka, is exploitable in
practice, and should be removed. A modified version of the CRIME
attack should be completely feasible. I can't imagine any remotely
feasible mitigation. Fortunately, I don't see any reason why removing it
(perhaps making the rpcapd option that turns it on do nothing) would
cause any compatibility issues.
2) What should the default verification behavior be? I worry about
breaking people's installs if suddenly it's enabled in enforcing mode by
default, but also most people are never going to bother to set things up
properly without incentive. A middle ground could be to have soft
failures by default - print a warning to stderr which can be turned of
by passing a command line option such as --insecure, with a --tls-verify
flag to make it a hard failure.
3) libpcap seems to lose track of the hostname between establishing the
control connection. Path of least resistance seems to be adding `char
*rmt_hostname` to `struct pcap_rpcap`, saved via strdup. Is this going
to upset anyone?
4) What level of control should be exposed for the tls settings within
5) If control over cipher suites is provided, standard tools don't
change TLSv1.3 settings via cipher suite list. I'm inclined to add some
cipher suite code that does sensible handling of TLSv1.3 cipher suites
alongside legacy config. Thoughts?
6) Would anyone be willing to hand-hold a bit on the "active" mode? It
seems a bit weird, and I'm not confident I understand what's going on.
More information about the tcpdump-workers