When the CLI establishes connection with the 3D it sends a first message containing the API url and the JWT used for authentication, which the CLI obtained when logging in with the username and password. Since this communication is via a tcp socket, it is not encrypted. Therefore, this secret token can be easily read by another process, for example, it can be seen using Wireshark:
Furthermore, the CLI does not perform any verification of which process it sends this information to, any process that accepts a connection on the correct port can receive it, for example a malicious process that is looking for this information in order to make API calls on behalf of the user.
To solve this we could:
- Transmit this information via a secure (encrypted) channel and where it is actually verified that the information is sent to an Ogree-3d process (complicated)
- Have Ogree-3d do its own authentication, avoiding the need to transmit the token
This same problem actually applies to all information that the CLI transmits to the 3D, so a malicious process could retrieve information of the datacenter
When the CLI establishes connection with the 3D it sends a first message containing the API url and the JWT used for authentication, which the CLI obtained when logging in with the username and password. Since this communication is via a tcp socket, it is not encrypted. Therefore, this secret token can be easily read by another process, for example, it can be seen using Wireshark:
Furthermore, the CLI does not perform any verification of which process it sends this information to, any process that accepts a connection on the correct port can receive it, for example a malicious process that is looking for this information in order to make API calls on behalf of the user.
To solve this we could:
This same problem actually applies to all information that the CLI transmits to the 3D, so a malicious process could retrieve information of the datacenter