timetoogo/ff-proxy

A UDP to TCP proxy server for sending HTTP requests with zero roundtrips

ff-proxy's Issues

Comments on the protocol design and potential security issues

Hi Elliot,

I am sure you had lot of fun developing this and hopefully you learned a lot. :)

Just a few suggestions based on a quick look on the description in the README, config.c, crypto.c and ff_client.py:

• If you ever want to proxy from one protocol to another, consider using socat. It is as easy as socat UDP-LISTEN:1234,fork TCP:example.com:80. It also supports TLS, see the SSL type in the examples section of its manual.
• The key passed via the --psk option may be visible in the process list, in the Docker outputs, etc. At minimum you could try to scrub the process list. Environment variables are slightly better, but they have the same issues with respect to introspection by others. Passing it through a file (or volume/secrets mounted through Docker) is slightly more secure.
• If the "psk" is just a passphrase, it should use a proper key-stretching function such as Argon2 as opposed to padding it to zeroes.
• Your encryption protocol is vulnerable to replay attacks and is not forward-secret. The same encrypted data could be sent multiple times, and if the PSK is ever revealed, all previous and future communication will be compromised.

Note that your "zero latency" claim is not entirely accurate, your FF proxy still need to do the three-way handshake. There are ways to reduce latency on the network however:

• You can use TCP Fast Open (RFC 7413). It is supported on Linux, enabled by default on Linux clients, but off by default for Linux servers. It allows data to be sent with the first TCP packet if the server was connected to before. Clients can also be configured to send it without the previous contact, but that may not work if the server does not support it.
• TLS 1.3 + TCP Fast Open or the UDP-based QUIC allow you to send "early data" with the first message. This usually requires you to have a session ticket from a previous session however.

Something that might not be taken into account by your design is packet reordering and loss. If you try to emulate a stream-oriented protocol on top of UDP, you become responsible for retransmission and reordering. From a quick look I don't see this addressed in the protocol design nor the client or server implementations.

If you are interested in protocol design, I suggest looking at WireGuard which has a 1-RTT handshake protocol on top of UDP. It uses ChaCha20-Poly1305 as AEAD as opposed to AES-GCM (which is also an AEAD), but more importantly, it keeps track of the record counters to avoid replay attacks. Try not to write your own cryptographic protocols though, you are most likely going to overlook something and make something insecure.

If you are up for another fun task, you could try to write a Wireshark dissector for your homegrown protocol. For this task I would recommend using Lua since its interface is slightly easier. See https://github.com/Lekensteyn/wireguard-dissector for an example and https://www.wireshark.org/docs/wsdg_html_chunked/wsluarm_modules.html for documentation.

Another suggestions is integrating with a fuzzer such as https://llvm.org/docs/LibFuzzer.html. I suspect that the option parser may explode, it looks a bit fishy. There are not sufficient length checks, something that is worrisome for a parser of external inputs.

Can't Import ff_client.py in Python

I'm pretty new to both python and docker, but I at least know some bits and bobs on python so I chose to install it from there. I can import all files listed except ff_client. Any idea why this is happening and how I can fix this?

README.md echo|netcat command won't work without -e

echo won't interpret backslash escape sequences by default, you need to specify -e:

echo -e "GET / HTTP/1.1\nHost: www.google.com\n\n" | nc -uw0 127.0.0.1 1234

error occurred during compeling

gcc (Debian 4.9.2-10+deb8u2) 4.9.2

make info printed:

mkdir -p build/obj/client
gcc -std=c99 -Wall -Wextra -c src/main.c -o build/obj/main.o
gcc -std=c99 -Wall -Wextra -c src/config.c -o build/obj/config.o
src/config.c: In function 'ff_parse_arguments':
src/config.c:33:13: warning: implicit declaration of function 'strcasecmp' [-Wimplicit-function-declaration]
if (strcasecmp(arg, "--help") == 0)
^
gcc -std=c99 -Wall -Wextra -c src/server.c -o build/obj/server.o
src/server.c: In function 'ff_proxy_start':
src/server.c:92:9: warning: implicit declaration of function 'getnameinfo' [-Wimplicit-function-declaration]
getnameinfo((struct sockaddr *)&src_address, src_address_length, ip_string, sizeof(ip_string), NULL, 0, NI_NUMERICHOST);
^
src/server.c:92:113: error: 'NI_NUMERICHOST' undeclared (first use in this function)
getnameinfo((struct sockaddr *)&src_address, src_address_length, ip_string, sizeof(ip_string), NULL, 0, NI_NUMERICHOST);
^
src/server.c:92:113: note: each undeclared identifier is reported only once for each function it appears in
Makefile:48: recipe for target 'server.o' failed
make: *** [server.o] Error 1

Windows Server

Can install server on win server?

destination port for client

Hi

thanks for your UDP client implementation ff-proxy. I know it's no more than a proof of concept, but when thing I don't understand is the lack of destination port for the client. I suppose that the client works as a bridge for the HTTP traffic being sent through a tunnel made with UDP. But I would like to use in connection with a browser. I tried the C client that is installed at the same time when is compiled from source but I don't see any port in which the client exposes a port which should be used with an application (like the browser) that speaks the HTTP protocol.

Best regards,
Samuel

Potential security issue

Hey there!

I belong to an open source security research community, and a member (@giridharprasath) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)