guyharris
commented
7 months ago From my testing, if I'm not mistaken, seems the TLS changes are done with backwards compatibility of old servers & clients in mind?
Either the server is configured to use TLS, in which case non-TLS connections get a "TLS is required by this server" error, or it's configured not to use TLS, in which case TLS connections get a TLS handshake failure error.
"Old servers & clients", if old enough, don't support TLS; the new client code, if rpcap rather than rpcaps is used, will connect to those old servers, and the new server code, if run without -S, will handle connections from those old clients.
I did a test with tcpdump compiled with libpcap remote enabled and SSL enabled on one machine, connecting against an rpcapd that didn't have SSL/TLS enabled, requesting rpcaps:// didn't throw error
When I did that test, I got
$ ./tcpdump --list-remote-interfaces rpcaps://127.0.0.1/
tcpdump: SSL_connect(): error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failuredoes it just fall back to rpcap if rpcaps/TLS is not available on the server side?
No, it doesn't. The author of the TLS support commented that
TLS for the control socket can be done in several ways though:
rpcapd -Scould wait for a TLS handshake right after the connection establishment of the control socket, but then clients must already know they have to issue this handshake, preferably without adding a command line parameter to every programs using libpcap. So I suggest we add a "rpcaps://" scheme so that libpcap can deal with this on its own. The "rpcaps://" scheme would fail if the server does not run with -S, or the client libpcap is not compiled with openssl support.Or
rpcapd -Scan send a special message before the authentication to request the client to establish TLS, aka a STARTTLS command. I regard opportunistic TLS like this as an ugly hack that makes the protocol more complicated to implement and debug, but the advantage is that older clients can still interoperate (it's not always an advantage though. One of the thing we really want to avoid is any kind of fallback to non-encrypted forward once rpcapd has been started with -S).I strongly favor the first alternative and will work on that.
and that's what they did - scheme 1.
And I assume if rpcapd is set to run with SSL/TLS (via -S), on unsupported clients requesting rpcap:// will it just serve the request over rpcap:// and not deny the request?
No. (And quietly falling back to non-TLS-encapsulated rpcap would be a big mistake - "surprise, your password went over the wire un-encrypted!")
Or does it actually enforce requests only through rpcaps://?
Yes:
$ ./tcpdump --list-remote-interfaces rpcap://127.0.0.1/
tcpdump: TLS is required by this server(that's a message sent back by rpcapd, so it might be "tshark: TLS is required by this server" or a Wireshark dialog saying that "TLS is required by this server" or...).
Also, rpcap client is supposed to do some certification validation of the cert provided by rpcapd but that looks to be pending #1080.
Yes. How does one do that with OpenSSL (or LibreSSL)?
I also saw this in the source code, glancing over it
static int uses_ssl; //!< '1' to use TLS over the data socketJust want to clarify data socket refers to the port specified by
-tor default when not specified? Does the SSL/TLS also get used for the control port (default 2002) that sets up the rpcap traffic? Since the user authentication is part of the control exchange and not packet capture data sent back.
uses_ssl is "the -S flag was passed to rpcapd". That comment probably dates back to before @rixed added support for TLS encapsulation of the control path, and needs to be updated. Both the control socket and, if the data socket is using TCP rather than UDP, the data socket use TLS. (Nobody's implemented DTLS support for a UDP data socket.)
Relating to that, the user authentication that you can supply from Wireshark GUI, when TLS is not used (on both Wireshark and rpcapd), is sent over the wire unencrypted in plain text? Just wanted to confirm.
Yes, that's how the rpcap protocol works. That's one reason to prefer TLS unless the remote capture is being done in a very well-controlled environment.
If so, that is just one step more secure than adding the user auth in the rpcap:// URL since either way it's still unencrypted over the wire, the GUI just hides the password more than passing it in the rpcap URL for CLI case (tshark, dumpcap, tcpdump)
Yes, although the CLI programs should be able to ask for the password from the terminal, so that 1) it's not in the command line and can't be seen with ps and 2) so that it's not echoed when the user types it. (They're not, but that needs to be cleaned up.)
Or is there some extra security how the Wireshark GUI approach handles the auth that I'm not aware of?
No - Wireshark 100% relies on libpcap's rpcap client code to do all the over-the-network stuff, including authentication.
infrastation
The TLS option is rather new and rpcap is not enabled by default for *nix platforms, and Windows doesn't yet support TLS for rpcap. So I did some testing for compatibility and mixed use cases. Thought I'd check here first before trying to look through the code for interpretation.
From my testing, if I'm not mistaken, seems the TLS changes are done with backwards compatibility of old servers & clients in mind?
I did a test with tcpdump compiled with libpcap remote enabled and SSL enabled on one machine, connecting against an rpcapd that didn't have SSL/TLS enabled, requesting rpcaps:// didn't throw error, does it just fall back to rpcap if rpcaps/TLS is not available on the server side?
And I assume if rpcapd is set to run with SSL/TLS (via
-S), on unsupported clients requesting rpcap:// will it just serve the request over rpcap:// and not deny the request? Or does it actually enforce requests only through rpcaps://? Like how some web servers only do https or will http redirect to https. In basic testing, it seems even with TLS enabled, rpcapd will still respond to rpcap requests under certain cases? It looks to only fail if the requesting rpcap client is known to support TLS but requests unsecured "rpcap://" anyways to the rcapd that has TLS enabled. I'll have to double check my test findings, but that is what I observed earlier.Also, rpcap client is supposed to do some certification validation of the cert provided by rpcapd but that looks to be pending https://github.com/the-tcpdump-group/libpcap/issues/1080.
I also saw this in the source code, glancing over it
static int uses_ssl; //!< '1' to use TLS over the data socketJust want to clarify data socket refers to the port specified by
-tor default when not specified? Does the SSL/TLS also get used for the control port (default 2002) that sets up the rpcap traffic? Since the user authentication is part of the control exchange and not packet capture data sent back.Relating to that, the user authentication that you can supply from Wireshark GUI, when TLS is not used (on both Wireshark and rpcapd), is sent over the wire unencrypted in plain text? Just wanted to confirm. If so, that is just one step more secure than adding the user auth in the rpcap:// URL since either way it's still unencrypted over the wire, the GUI just hides the password more than passing it in the rpcap URL for CLI case (tshark, dumpcap, tcpdump). Or is there some extra security how the Wireshark GUI approach handles the auth that I'm not aware of?