4 ms·

Some things I noticed about the proposed protocol: - It's not clear how data is encrypted. I don't see a client key being generated. It will be very difficult

by nvarsj 10y ago

Some things I noticed about the proposed protocol: - It's not clear how data is encrypted. I don't see a client key being generated. It will be very difficult to do this right without using something like TLS. Are the keys just sent over an unencrypted channel? - The connect token should contain the client's IP address, so the server can verify the same IP that got the token is trying to connect. This prevents someone from using a valid token for reflection attacks.

IshKebab 10y ago
Presumably the keys are sent over HTTPS.
- gafferongames 10y ago
  Yes, the connect token is transmitted from web backend to client over HTTPS. This token contains public and private data. The public data tells the client which servers to connect to, what the keys are etc, hence the need for HTTPS. The private data is what gets sent over UDP in connection handshake, and is encrypted with a libsodium AEAD primitive using a private key shared between the backend matchmaker and the dedicated server instances. Because of this clients cannot read, modify or forge the connect token private data, so cannot connect unless they get a token from the backend. Tokens are only valid for a specific authenticated client to connect to a small set of n dedicated servers, and expire quickly (30-45 seconds).
hach-que 10y ago
The symmetric key / connection token is generated with netcode_generate_connect_token. This is normally done on your authentication server, which runs over normal HTTPS. Thus the workflow is basically like this: - Web browser connects to like https://auth.myapp.com https://auth.myapp.com. This can either be part of the login process or server discovery, it's totally up to you and specific to your app. This service calls netcode_generate_connect_token and returns the symmetric key / connection token in the response. - The client then uses this symmetric key / connection token when calling netcode_client_connect. - And you're done, you can now use the rest of the netcode APIs. The second thing that you mentioned isn't required. The token is unique to the client already, so a server can confirm that it's a specific client connecting.

by nvarsj 10y ago

IshKebab 10y ago

Presumably the keys are sent over HTTPS.

gafferongames 10y ago
Yes, the connect token is transmitted from web backend to client over HTTPS. This token contains public and private data. The public data tells the client which servers to connect to, what the keys are etc, hence the need for HTTPS. The private data is what gets sent over UDP in connection handshake, and is encrypted with a libsodium AEAD primitive using a private key shared between the backend matchmaker and the dedicated server instances. Because of this clients cannot read, modify or forge the connect token private data, so cannot connect unless they get a token from the backend. Tokens are only valid for a specific authenticated client to connect to a small set of n dedicated servers, and expire quickly (30-45 seconds).

hach-que 10y ago

The symmetric key / connection token is generated with netcode_generate_connect_token. This is normally done on your authentication server, which runs over normal HTTPS. Thus the workflow is basically like this: - Web browser connects to like https://auth.myapp.com https://auth.myapp.com. This can either be part of the login process or server discovery, it's totally up to you and specific to your app. This service calls netcode_generate_connect_token and returns the symmetric key / connection token in the response. - The client then uses this symmetric key / connection token when calling netcode_client_connect. - And you're done, you can now use the rest of the netcode APIs. The second thing that you mentioned isn't required. The token is unique to the client already, so a server can confirm that it's a specific client connecting.