-
Notifications
You must be signed in to change notification settings - Fork 4
8.Security
All secure TCP variants are implementing standard SSL socket with TLS authentication/validation.
In case of P2P systems same strategy is applied for the TCP connection. if Peer A wants to communicate between Peer B through TCP, it sends a message to Relay server through its SSL connection. Relay server Decrypts the routing info and obtains the destination peer. Then sends the message with the SSL connection of peer B
Considering the UDP where there is no TLS authentication (not provided by .NET), instead Symetric Key AES encrption is used. Key exchange is done by using previously authenticated SSL connection. Each peer has its own key, generated by the Relay server with secure random at runtime upon connection. This key is not shared and only provides communication with Relay server. If peer A wants to talk with peer B through UDP via Relay server, Peer A sends an encrpyted message to Relay. Relay then decrypts the routing info and obtains the destination. Then encrypts the message with destination peers AES key. This way no peer can know each others keys where Relay server acts as security bridge.
This scenraio assumes Relay server is trusted and not tempered with for man in the middle attacks. This essentially all boils down to chicked and egg problem. Where we need to validate the servers certificate with a trusted authority. Unfortunately this is a paid service for internet use case and i leave it up to the user.
In case of holepunching, during the procedure with two peers, Relay server generates a key to be shared between two peers. If the procedure succeeds, PeerA and B will use this symetric key to directly communicate. Of course this key exchange is also done with secure SSL channel.
The certificates(.pfx files) located in library are just placeholders, they are generated using OpenSSL only for test purposes. Eventhough they provide encrption, they are publicly avaibale hence not secure. You should generate your own certificates for usage. Alternatively use provided in self signed generation system for ephimeral keys but in that case you cant authenticate.
Multiple Aes modes of operation is implemented. Modes can be configured on relay client and server
GCM is highly reccomended and second best is CBC with HMAC.
All implementations use native hw accelerated versions if platform allows it.
NET 5+ and NetStandard 2.1 supports hw accelerated versions.
In case of .Net Standard 2.0 GCM is managed because platform does not support it. Cbc is hw accelerated.
GCM on .NET standard 2.1 is tested on Unity without an issue.
Clients with different aes modes can communicate with each other. You dont need to sycronise modes.