| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
The OpenSSL library on the current AppVeyor Visual Studio 2019 images
has a weird opensslv.h that claims its 1.0.2, even though it's 3.0.
This causes... problems.
For now, we disable the remote capture build there.
Back out the debugging stuff and the attempt to fix it in sslutils.c -
the weird opensslv.h causes that not to work.
|
| |
|
|
|
| |
This purports to be 3.0, and doesn't offer some old routines, but is
claiing to be 1.0.2!
|
| | |
|
| |
|
|
|
|
|
| |
The Shiny New OpenSSL 3.0.8 on the AppVeyor images with Visual Studio
2019 and later are missing some routines that have, apparently, been
deprecated since 1.1.0. If we have OpenSSL 1.1.0 or later, use the
replacements.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SSL_set_fd() takes an int as its second argument; that's not an issue on
UN*X, as sockets are represented by file descriptors, but causes
warnings on Windows, where a SOCKET is not an int.
A comment in OpenSSL's intternal sockets.h header says, on 64-bit
Windows:
Even though sizeof(SOCKET) is 8, it's safe to cast it to int,
because the value constitutes an index in per-process table of
limited size and not a real pointer.
so the cast should be safe.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Require Visual Studio 2015 or later; fail if we don't have it, and
remove checks for older versions.
That means we have C99-compliant snprintf() and vsnprintf(); require
them when configuring for UN*X, and then use them directly, rather than
having wrappers for systems lacking them.
If we're using MSVC, skip the tests for options to request C99
compatibility - either we have VS 2015, which is sufficient, or we
don't, in which case we fail.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
| |
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.
|
