encrypted UDP

[drzraf]

What?

Provide encrypted UDP support.
No need for asymmetric cryptography & certificate. "Only" symmetrically encrypt UDP packets using a per-stream shared-secret (possibly derived from the write token) with a stream-based encryption algorithm.

Why?

UDP is very important in many cases due to it "send-and-forget" nature. No handshake, no wait/timeout.
For being unencrypted it's not suitable in scenarios where logs have to move outside a datacenter.
DTLS, as any handshake-based protocol, implies the client could bug/timeout if the server isn't online what is often less desirable than loosing logs entries.

A state-less symmetric encryption could solve this.

Example:

On server-side, that means creating a UdpCrypto transport class like:
https://github.com/Graylog2/graylog2-server/blob/20ab7325eb82ec09c08ece0433e183412f32a05d/graylog2-server/src/main/java/org/graylog2/inputs/transports/UdpTransport.java

On the client, using the secret token as a key, it would be fairly easy to just [pipe client and server]
(https://gist.github.com/leonklingele/d5bd28ee51a4b8e49baa) into openssl enc -aes-256-gcm -k $SECRET -e.

Possible issue: Multiple streams

The netcat-client side is trivial.
But since server's socket listens to multiple streams, a cleartext "stream" id, distinct from the write token, may have to be prepended to packet, in cleartext to allow stream-identification by the server then allowing decryption using the adequate shared-secret.

Possible issue: Stream ID reply + wrong encryption key.

The decrypted payload must be checked. AES GCM provides built-in authentication tag mechanism to ensure decrypted content consistency. The tag could be the write-token.

Possible issue: Packet replay

Nothing the client can do against this (without modifying payloads).