| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Before we shut down the socket, send a shutdown alert. That should
prevent some cases where errors are reported when they shouldn't be (it
was happening if I did a --list-remote-interfaces in tcpdump).
While we're at it, do the SSL shutdown *before* closing the main active
socket; we were doing it *after*. Also, fix a comment.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we do the accept() ourselves, we get only one socket on which we send
and from which we receive messages.
If we're run by an inetd-compatible daemon, it does the accept() and
gets only one socket, which it proceeds to dup and hand to us as the
standard input, output, and error; we really only need to use one of
them.
In the latter case, just dup the standard input, and then close the
standard input, output, and error as we dup a descriptor for /dev/null
to them.
In both cases, just hand the one control socket to daemon_serviceloop().
Close it in daemon_serviceloop() before it returns, rather than in the
caller after it returns.
Only free the SSL structure for the control connection right before we
close the socket for the control connection; we don't need to free it
when we close a data connection.
|
| |
|
|
|
|
|
|
| |
Including WinSock headers is a game of Whac-A-Mole - if you ever get
winsock.h included before ws2def.h, you get a pile of errors, so you
have to be careful to include headers in just the right order.
See if this keeps moles from popping up.
|
| | |
|
| |
|
|
| |
Put it in portability.h as well, with redefinition protections.
|
| |
|
|
|
|
|
|
|
| |
Have routines that set them, given a pointer to the name. Use that in
rpcapd, rather than copying to a buffer (you don't need to copy strings
from argv - unless you're going to overwrite them, which you probably
shouldn't do).
This removes a requirement for the platform to define PATH_MAX.
|
| |
|
|
|
| |
Export ssl_init_once(), get rid of init_ssl_or_die(), and, in rpcapd, if
ssl_init_once() fails, use rpcapd_log() to log the error.
|
| |
|
|
| |
That squelches some unused parameter warnings.
|
| |
|
|
|
|
|
| |
We really shouldn't be including it in *any* header file, but we
*definitely* don't need to, and shouldn't be, including it *here*. All
of our source files should be including it as the first header file, so
there shouldn't be any need to include it in any other header file.
|
| | |
|
| |
|
|
| |
Cert file option changed from -C <file> to -X <file> (X as in X.509)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch also encode the control sockets in adition to the data
socket. Clients performs a TLS handshake when the scheme is rpcaps://
rather than rpcap://. Both active and passive modes are supported, but
transfert via UDP is not (yet) supported (the lib returns an error in
that case).
I did some adaptation to the windows code but couldn't tested so for all
I know it may not even compile.
Also tried to fix the indentation.
|
|
|
When using rpcapd one may want the forwarded traffic to be encrypted.
When running rpcapd via initd it is relatively easy to add stunnel but
the client still have to implement TLS. Or one could also use an ssh
tunnel but it's a lot of setup. Ultimately, it is simpler than rpcap
protocol could run on SSL natively. So this patch adds a -S option to
rpcapd that will wrap the data socket into a TLS tunnel (in both passive
anbd active mode, as long as it's TCP not UDP).
The start capture message has an additional flag: ssl, asking the client
to initiate a TLS handshake once he is connected to the data socket.
This patch is not polished as I'm more interested in early opinions at
this stage. Please let me know what you think of the idea and its
implementation so far.
Proof of concept:
generate a private key, a self signed root cert:
$ openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 36500 -out cert.pem
then run rpcapd with option -S (ssl) and -K and -C:
$ rpcapd -n -S -K key.pem -C cert.pem
Once recompiled, tcpdump can attach to this rpcap:// service and the
traffic will be encrypted.
|
