You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/_docs/advanced-topics/message-encryption.md
+15-4Lines changed: 15 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,12 +3,23 @@ title: Message Encryption
3
3
permalink: /wiki/message-encryption/
4
4
---
5
5
6
-
### Inner Workings
7
-
If Encryption is enabled in the NetworkConfig, a ECDHE Keyexchange will take place to establish a shared key, unique for every client and session. If SignKeyExchange is also enabled, the Server will provide it's SSL certificate for the client to use. This is essentially a clone of the TLS handshake and validation.
6
+
Because cryptography is a topic not many developers are familiar with. It will be explained in two parts, one "beginner friendly" and one highly technical explanation.
8
7
9
-
The certificate validation method can be changed with a delegate in the CryptographyHelper, but it defaults to the default .NET validation and checks that the hostname is valid or is "127.0.0.1", note that the certificate only has to be set on the server and only PFX formats is supported. The PFX Base64 string has to include the private key.
8
+
### The Beginners Version
9
+
If you enable Encryption in the NetworkConfig on the NetworkingManager, the server will agree to a key with each client that connects. This key can then be used to encrypt and authenticate messages. If someone is trying to break the encryption, they can do a MITM (man in the middle) attack, and neither party will know that someone is eavesdropping on the conversation.
10
10
11
-
If you want to use custom encryption or just need a shared secret between the server and client, you can grab the key that the MLAPI got in the handshake key-exchange from the CryptographyHelper.
11
+
To prevent MITM attacks, you need to enable the "Sign Key Exchange" option. When this option is enabled, you also need to supply a certificate and a private key. To get started, follow the instructions found [here](https://cert.midlevel.io/) for really easy steps. Note that this only works for dedicated servers, you cannot secure a communication between two clients (Player hosted).
12
+
13
+
### Advanced Explanation
14
+
If you enable Encryption in the NetworkConfig on the NetworkingManager, the server will always do a ECDHE implementation with every client to negotiate a key that is then stretched with PBKDF2.
15
+
16
+
To prevent MITM attacks, you need to enable "Sign Key Exchange" and supply a private key and a certificate, encoded as a PFX file in base64. The PFX Base64 string has to include the private key. This should only be done on the server. You can then add custom validation code to the clients for your certificate.
17
+
18
+
The certificate validation method can be changed with a delegate in the CryptographyHelper, but it defaults to the default .NET validation and checks that the hostname is valid or is "127.0.0.1".
19
+
20
+
If you want to use custom encryption or just need a shared secret between the server and client, you can grab the stretched key that the MLAPI got in the handshake key-exchange from the CryptographyHelper.
21
+
22
+
For quick development certificates, you can go [here](https://cert.midlevel.io/) to get one.
12
23
13
24
### Encrypted and/or Authenticated RPC
14
25
Since encryption can be quite intimidating for many new programmers. The MLAPI makes it super easy to encrypt and authenticate your rpc messages. This is the most common way of using encryption in the MLAPI.
0 commit comments