--- Begin Message ---
On Jul 4, 2022, at 4:49 PM, Ryan Castellucci via tcpdump-workers
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
