[tcpdump-workers] RFC: TLS in rpcaps

Guy Harris gharris at sonic.net
Tue Jul 5 03:27:16 EDT 2022

On Jul 4, 2022, at 4:49 PM, Ryan Castellucci via tcpdump-workers <tcpdump-workers at lists.tcpdump.org> wrote:

> 1) TLS compression support is a foot-bazooka, is exploitable in practice, and should be removed. A modified version of the CRIME[1] 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.

The only thing that -C appears to do is cause ssl_init_once() to call SSL_COMP_get_compression_methods(), which, according to


"returns a stack of all of the available compression methods or NULL on error.", so I'm not sure what -C, which is presumably "the rpcapd option that turns [TLS compression] on", actually *does*.

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

What does "setting things up properly" involve?  Presumably it's something more than just "not having an expired certificate"; if somebody can't be bothered to do *that*, my sympathy is limited.

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

It's a private data structure, and it consumes very little memory unless you have a huge number of pcap_t's open, so I'm not sure how much justification is there fore being upset.
> 4) What level of control should be exposed for the tls settings within libpcap?

What settings are there that might be exposed, other than "should I check the validity of certificates"?

> 5) If control over cipher suites is provided, standard tools don't change TLSv1.3 settings via cipher suite list.

"Standard tools" meaning "programs that use TLS" or something else?

And does "control" mean "disallow cipher suites that are allowed by default", "allow cipher suites that are disallowed by default", or something else?

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

"Active mode":


is a hack to allow remote capture from interfaces on a firewalled remote machine.  To start a capture, a capture program that supports active mode would be run on the client machine, and it would open a listening socket for rpcapd.  rpcapd would then be run in active mode on the machine on whose interface(s) capture is to be done, with the host name/address and port number of the capturing application provided as arguments to the -a flag, and would attempt to connect to that host and port.  Once the connection is made, the capturing machine (the machine that *accepted* the connection) would send an authentication request message to the machine on whose interface(s) the capture is to be done (the machine that *initiated* the connection), and that and all messages would work exactly the same was as if the capturing machine had initiated a connection to the machine on whose interface(s) the capture is to be done.

So the only part of the traffic that changes is the connection initiation.

Given that there are, as far as I know, zero capturing programs that support the not-exactly-clean API for active model (neither tcpdump nor Wireshark do), I've never tested that even without* TLS, much less *with* TLS, so that may require work even before any additional work is done.

I'd like to make remote capture work with the create/activate API, which might allow a cleaner active mode API, with less hackery necessary for programs to use it.

More information about the tcpdump-workers mailing list