Secure server connection

[heinrich5991]

The current low-level protocol should be augmented or replaced by something that can give us cryptographic guarantees that we connect to the right server and that no one can listen to our chat messages, passwords or rcon passwords.

This would also enable decentralized accounts (#3411) in a nice way. The client could simply authenticate against a shared secret of the connection, like in ssh. This way, the authentication cannot be spoofed, replayed or forwarded.

This also allows to use reverse proxies without trusting them with player data.

My current proposal would be to use QUIC as the underlying transport. I'm open to other suggestions.

QUIC runs atop UDP, so we don't give up compatibility. QUIC supports ordered streams (to be used for reliable NETSENDFLAG_VITAL messages) and datagrams (to be used for unreliable messages without the NETSENDFLAG_VITAL flag). The QUIC protocol uses TLS 1.3 for its security.

[heinrich5991]

The TLS protocol uses certificates to authenticate servers. This doesn't quite match what we want to do. Our trust model could be trust on first use (and then continue to identify the server based on its cryptographic identity), or trust based on our own certificates. Getting publicly-trusted certificates seems too much of a burden for server administrators.

TOFU wouldn't need server certificates, so should we simply not have them?

Open question: What to do with the existing TLS certificate stuff around QUIC? Play with it and let the masterserver hand out certificates? If so, what happens with LAN servers? Or should we do away with the certificate based authentication? Is that even supported by TLS?

[def-]

QUIC, compared to a self-rolled solution, also sounds good because firewalls will know about it.

[Learath2]

I like the idea of QUIC, but it's a lot of work to get it in, I wonder if DTLS would be a more realistic goal.

When it comes to server certificates, we could run our own CA. Without authentication server impersonation is a big issue. This does imply a bit of centralization though, not sure if you'd like that. Hosters that don't want to/don't feel like applying for a certificate can just use self signed ones as on the web.

TLS can run without certificates, but again no authentication. DH_anon is the keyword.

If we want TOFU how do we handle a server certificate getting leaked or lost? I don't think TOFU can provide any authentication unless the user is very vigilant and savvy. Having the masterserver provide the certificates means the masterserver gets to impersonate anyone, so not sure about the benefit of that compared to running a CA.

I guess auto generated self signed certificates solve the LAN problem, we could also disable the check in the private reserved ip blocks to make it even more convenient.

[heinrich5991]

I want to work on this.

Wikipedia has a list of QUIC implementations. I'd prefer to use one written in Rust. This will probably run into problems with our minimum supported Rust version. Also, Rust code is typically not dynamically linked, which would mean that we'd have two copies of QUIC for server an client, which is also bad.

• quiche: Written in Rust, uses boringssl as backend. boringssl isn't packaged for any distribution AFAICT and conflicts with openssl. We could link our curl against boringssl but then we'll get problems with Linux distributions. Used and written by Cloudflare, so probably has a future.
• quinn: Written in Rust, uses ring as backend. Doesn't conflict at least.

Anyone got experience with QUIC libraries?

[Learath2]

I've already voiced my concern about replacing a core part of the game with Rust code. I think you are better suited to evaluate whether it is possible and how than me.

I probably would go for quinn if it'll be in rust if only to avoid the annoying boringssl dependency. If we decide to stick to C/C++ for this, we should probably rely on something backed by a large corporation, there are 3 of those (msquic, mvfst, quiche) only msquic doesn't use boringssl, so that.

[heinrich5991]

msquic uses the openssl fork with quic support. I think this has a chance of getting packaged into debian and the likes. I think it doesn't have support for macOS though, so it's a non-starter.

I wonder whether the other libraries also work with that fork (by Microsoft and Akamai), as it describes itself as "maintained version of openssl/openssl#8797, which in turn describes itself as "boringssl quic API implementation for openssl".

[Avolicious]

When it comes to server certificates, we could run our own CA. Without authentication server impersonation is a big issue. This does imply a bit of centralization though, not sure if you'd like that. Hosters that don't want to/don't feel like applying for a certificate can just use self signed ones as on the web.

Add to the info endpoint: "https://info.ddnet.org/info" a "trusted_root" where you can store a location where the root_ca of the specific community has been saved. So clients can fetch and all signed certificates from that root are trusted for the specific community.

In order to allow automatic certificate management, we could also rely on ACME.