Andrei486
commented
7 months ago Findings:
TLS will guarantee that an attacker without access to the application will not be able to read intercepted messages, preventing information from leaking. However, we have the problem that we need to set up and use certificates for TLS. Creating a self-signed certificate is easy via the keytool command-line utility, and we can also create certificates signed by our own self-signed certificate.
However, the problem comes when we need to include these in our application. The application must somehow have access to these certificates, both to use them when acting as a server by including them in a keystore, and to include in a truststore so that as a client we know what a trusted server certificate looks like. Since we have no server/central node, our only option would be to include the certificate(s) in the application, likely providing a keystore and truststore, along with the keystore password.
Unfortunately this means that an attacker with the application could build a custom client to conduct man-in-the-middle attacks, using the existing keystore and certificates to relay and read messages after intercepting a new client connection.
Two possible ways to use TLS would be:
- simpler way: make one certificate, add it in a keystore and truststore, and include both of those in the app, setting system properties via config/code so that the app uses those. The certificate will be the same for all users.
- complex way: make one "root" certificate, add it in a truststore, have an empty keystore and include both of those in the app, setting system properties via config/code so that the app uses those. On startup (if it has not been done already), take the root certificate, create a new certificate signed by it, and add that to the keystore to use. The certificate will be different for all users, but all users will have access to the "root" certificate used to create these trusted certificates.
The problem with the second option is that it does not really help against an attacker with the app. The attacker could simply create their own trusted certificate (or just take the app's once it makes it) so that they can conduct the same man-in-the-middle attack, since the client cannot know which specific certificate they are connecting to. There might also be complications with creating the certificates and modifying keystores on the fly, it's easy via command line but it requires keytool and openssl to be installed.
It could be possible to use TLS if we had a database that mapped room code -> certificate, and a secure connection to that DB. However we would need to secure the DB connection and the API key, but the API key would need to live in the code which leads to the same problems we're having with the keystore password: no effective way to hide it.
Recommendation: If we use TLS without major changes to the system (likely involving some kind of central server node) we can include a keystore/truststore of certificates shared among all copies of the application. This will protect information against attackers who do not have the application, but an attacker with the application could create a custom client to get around that security. We need to have a discussion about who/what we are willing to secure against.
One option for encrypting communications would be to use TLS, which would encrypt communications for us using JSSE and Socket/ServerSocket subclasses. This would require us to use certificates and likely generate them ourselves. Investigate the feasibility of using TLS with certificates, and various ways to generate them.