Feature: optional network encryption support

[vl-gx]

Current app status

Ioq3 client server networking model relies on UDP and, by default, does not use encryption at all.

Modern, newer games engines like Unity or UE provide encryption as an optional feature for developers and/or players/servers owners.

Old q3 clients and server executables relied on XOR obfuscation at the time they were closed source, then removed with the q3 source release for performance and/or uselesness reasons.

It was already discussed on the forum discourse.ioquake.org/t/encrypting-q3-traffic/1531 but in a less convincing approach.

Implementation goals

Provide in-game options for players and server administrators to secure data exchange during network comunication by providing protection against:

• eavedroping
• tampering (Man in the Middle)
• message forgery

Architecture wise, a secure, safe choice to provide thoses security properties to ioq3 protocol would be to use Datagram Transport Layer Security (DTLS) Protocol as specified in datatracker.ietf.org/doc/html/rfc9147.

Shipped with proven recent ciphers suite, DTLS is standardised. It is preffered to redesigning a custom integration of known crytographic functions within the game protocol.

Using DTLS with ioq3

Overview

Ioq3 protocol provides a design server side where a system minimize the size of each UDP datagram while compensating for the unreliability of UDP.

DTLS is to construct "TLS over datagram transport". Datagram transport neither requires nor provides reliable or in-order delivery of data. The DTLS protocol preserves this property for application data.

Online gaming and more specifically, ioq3 uses datagram transport for communication, due to the delay-sensitive nature of transported data. Behavior is unchanged when DTLS protocol is used to secure communication, since the protocol does not compensate for lost or reordered data traffic.

DTLS can encapsulate ioq3 payloads as-is by providing an additional layer of encryption, as long as the DTLS handshake happens beforehand.

Since DTLS optionally supports record replay detection, ioq3 client would have to force cl_paquetdup to 0 when using encryption.

DTLS Handshake

DTLS reuses TLS handshake messages and flows. DTLS handshake messages are grouped into a series of message flights. A flight starts with the handshake message transmission of one peer and ends with the expected response from the other peer.

DTLS Handshake happens during the initial connection to the server, not with each datagram. The configuration of timeout timer settings varies with implementations, but can be adjusted from a few ms to a few seconds.

DTLS Record Layer

Application data messages are carried by the record layer and are split into records and encrypted based on the current connection state.The messages are treated as transparent data to the record layer.

Implementation details

First, follow best practices with the inclusion a production ready, statically linked crypto library, compatible with the ioq3 license (Gnu GPLv2).

Recent versions of wolfSSL (which uses (Gnu GPLv2), see wolfssl.org) are compatible and provide a verified implementation of DTLS 1.2 and 1.3.

The feature would be optional for clients and servers, but each one could enforce one side to use encryption, by using a cvar and server variable:

net_encrypt_enable 0|1 net_encrypt_cipher 'DTLS_AEAD_AES_128_CCM_8'

Finally, update the MAKEFILE to compile executable with and without the lib, for users or server owners uninterested by the feature.

ifeq ($(USE_SSL),1)
    CLIENT_CFLAGS += $(SSL_CFLAGS)
    ifneq ($(USE_SSL_DLOPEN),1)
      ifeq ($(USE_LOCAL_HEADERS),1)
        CLIENT_CFLAGS += -DSSL_STATICLIB
        ifeq ($(ARCH),x86_64)
          CLIENT_LIBS += $(LIBSDIR)/include/wolfssl
        else
          CLIENT_LIBS += -lwolfssl
        endif
      else
        CLIENT_LIBS += $(SSL_LIBS)
      endif
    endif
  endif

Potential benefits/costs for players

(+) increase player privacy, totally in scope with internet privacy laws like EU's GDPR (+) a protection against certain cheats (but nothing complete) (+) mandatory only for servers that enforce it

(-) additional latency overhead, typically increases player ping around 0.12ms more than normal for AES based ciphers, + about 1 s for additional DTLS Handshake during connection. (-) complexity increases in codebase maintenance and size, since we have to deal with the library vulnerabilities and updates.

Platform used for compilation

Windows 10 x64 with Cygwin, Eclipse C/C++ IDE

[Calinou]

I'm not convinced there would be a lot of potential users for this feature, considering most servers (and many clients) won't upgrade from whatever version they're using anytime soon. The Quake 3 client/server scene is pretty fragmented already.

(-) additional latency overhead, typically increases player ping around 12ms more than normal for AES based ciphers,

That's a lot of overhead for a competitive shooter, especially considering the default server tickrate is 20 Hz (which comes with 50 ms latency on its own already). I'm surprised the overhead is this high with AES-128 encryption, even on a modern CPU.

[quakemmo]

Might want to check out my fork of ioq3. It includes AES encryption without latency increase. https://github.com/quakemmo/xqc The relevant files are mostly in qcommon/

[vl-gx]

(-) additional latency overhead, typically increases player ping around 12ms more than normal for AES based ciphers,

That's a lot of overhead for a competitive shooter, especially considering the default server tickrate is 20 Hz (which comes with 50 ms latency on its own already). I'm surprised the overhead is this high with AES-128 encryption, even on a modern CPU.

A typo slided in during my post, and one had to read "0.12", instead of "12".

With 12ms it would have been much less comfortable for players to play, even on public servers.

In the meantime, you are absolutely right for the AES and CPU part since specific instruction sets exists for AES in Desktop CPUs for quite some time now.