Re: RFC: TLS in rpcaps

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Tue, 5 Jul 2022 00:27:16 -0700
>
> On Jul 4, 2022, at 4:49 PM, Ryan Castellucci via tcpdump-workers <tcpdump-workers () 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
>
>         https://www.openssl.org/docs/man3.0/man3/SSL_COMP_get_compression_methods.html
>
> "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":
>
>         https://www.winpcap.org/docs/docs_412/html/group__remote.html#RunningModes
>
> 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.
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers