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
When using the Registry without WebRTC, LAN or direct TCP connections to MapTool servers the connection is not encrypted and the authenticity of the MapTool server is not verified.
This feature can be considered related to #5063 in that they are both required to ensure
This can be considered a precondition of features like #5163 where it's not the integrity of the game's data model that's being protected, but the user's system, and direct file access is significantly more exploitable so needs to be protected against MITM attacks.
The Solution you'd like
MapTool supports connecting over SSL for servers that sysadmins have very carefully configured SSL tunnels to.
MapTool generates self-signed certificates from the existing RSA key.
The RSA key and self-signed certificate are provided through a KeyManager
passed to SSLContext.init.
At this point users have to install the server's self-signed certificate into their OS cert store themselves.
MapTool provides an interface for clients to copy pre-shared self-signed certificates that were sent by secure back-channels into a MapTool-specific certificate store. That is used by a custom TrustManager passed to SSLContext.init.
Servers send their certificate to the MapTool registry and clients add the certificate to their certificate store automatically so all that groups need to do to use SSL is for the host to tick a box in the UI.
Extend the LAN announcement packets to include SSL certificate so it's just Direct TCP connections that need to have the certificates pre-shared.
Alternatives that you've considered.
Concentrate on #5063 but that abandons users who don't use WebRTC to less secure connections and inability to offer certain features.
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Describe the Problem
When using the Registry without WebRTC, LAN or direct TCP connections to MapTool servers the connection is not encrypted and the authenticity of the MapTool server is not verified.
This feature can be considered related to #5063 in that they are both required to ensure
This can be considered a precondition of features like #5163 where it's not the integrity of the game's data model that's being protected, but the user's system, and direct file access is significantly more exploitable so needs to be protected against MITM attacks.
The Solution you'd like
MapTool supports connecting over SSL for servers that sysadmins have very carefully configured SSL tunnels to.
MapTool generates self-signed certificates from the existing RSA key.
The RSA key and self-signed certificate are provided through a KeyManager
passed to SSLContext.init.
At this point users have to install the server's self-signed certificate into their OS cert store themselves.
MapTool provides an interface for clients to copy pre-shared self-signed certificates that were sent by secure back-channels into a MapTool-specific certificate store. That is used by a custom TrustManager passed to SSLContext.init.
Servers send their certificate to the MapTool registry and clients add the certificate to their certificate store automatically so all that groups need to do to use SSL is for the host to tick a box in the UI.
Extend the LAN announcement packets to include SSL certificate so it's just Direct TCP connections that need to have the certificates pre-shared.
Alternatives that you've considered.
Concentrate on #5063 but that abandons users who don't use WebRTC to less secure connections and inability to offer certain features.
Additional Context
No response
The text was updated successfully, but these errors were encountered: