All geek questions in one place

If I use SSLSocket in Android and hard code, is the proxy access code in the source code unsafe?

I use Java SSLSocket to securely connect an Android application to the server. The certificate is in a trusted store. But the power of attorney access code is apparently required for the connection, and therefore it is currently hardcoded into the device. I do not know much about PKI, but it does not seem safe. I associate a trust store with an application in the source folder. Is there a better approach to securely connecting an application to a server using TLS? I am very new to TLS / SSL, so I would appreciate any help or recommendations.

Here is the client side of the code.

store = KeyStore.getInstance("BKS"); InputStream in = appcontext.getResources().openRawResource(R.raw.truststore); store.load(in, "PASSWORD".toCharArray()); TrustManagerFactory tmf = TrustManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm()); tmf.init(store); sslcontext = SSLContext.getInstance("TLS"); sslcontext.init(null, tmf.getTrustManagers(), new SecureRandom()); SSLSocketFactory sslsocketfactory = sslcontext.getSocketFactory(); // connect to socket SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket( "192.168.1.16", 9999);
+4
source share
2 answers

I have not tried Android, but here is how it works in simple Java.

You are using the keystore as a trust store here, so (hopefully) it does not contain any secret key or secret material. In this case, the purpose of the password is to check the integrity of the repository.

From the Keystore.load(InputStream, char[]) documentation :

You can specify a password to unlock the keystore (for example, the keystore is located on a hardware token device) or to verify the integrity of the keystore data. If a password is not specified for integrity checking, then integrity checking is not performed.

Either you use null as the password (in this case you can always download certificates), or use an array with a non-zero char with the actual password (in this case, the wrong password will fail with something like "java.io.IOException: Keystore has been changed , or the password was incorrect ").

Using a password here means increased security (to prevent tampering). At the same time, if you combine both of these trust stores and this application together, most likely, an attacker who can replace the trust store will also gain access to the password (by decompilation) in any case. (I'm not very familiar with the Android application distribution, but if the applications are signed, it is possible that faking raw resources like your trust store will also invalidate the signature, which may be a more realistic way to provide this protection. Otherwise, I I think you can ask the user to enter a trust password each time, but that seems unrealistic.)

This is not part of your question, but to ensure an SSL / TLS connection, you also need to check that the certificate sent by the server is valid for the host name you tried to reach after SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket("192.168.1.16", 9999); .

This has been discussed recently in this issue in Java. (Unfortunately, you will not be able to use the new Java 7 API for this automatically for you on Android, so you will have to check the certificate a little more manually. You may also be interested in this recent question .)

EDIT (after your comment):

I am worried that someone will recompile the application, access code and trust store and use it to connect to my server. If possible, this partly hits the TLS target in the first place.

From this comment it is not clear that you understand the purpose of the trust store (see this question , for example).

The goal of a trusted store in your client application is not to authenticate your application on the server, but to verify that your client can verify the identity of the server to which it connects, so that it cannot be tricked into connecting to an attacking MITM. This is not about how your server trusts your application / client / user, but how your application trusts your server.

Authenticating the user of the application to the server will be the purpose of the keystore. This is great for user authentication (but it makes sense if each user has a different certificate). To make sure that connections can only appear from your application is another, much more complex problem (a lost reason if you do not have full control of the client equipment at any time). Using a common client certificate in your application may buy you a little time, but anyone who has taken possession of the client code can, in the end, rebuild it. I would not spend too much time on this. You may be interested in the following questions:

+5
source

Problem: Everything that you include in your source code can be read by anyone who received the apk file. Therefore, if you include your access code and trust store in your source code (or resource files), it can be read by anyone with apk.

In fact, it is not possible to guarantee that the application connecting to your server is your own application. Imagine a modified Dalvik VM that waits for your application to launch SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket("192.168.1.16", 9999); and then transfer sslsocket to another application.

Decision:

  • Transfer your trusted code to the server. For example, if you have a method in your application called addNewProductDirectlyToDatabaseOnServer , replace it with the addNewProductToServer method and ask it to call the REST API for your server, which will add a new user, preventing malicious applications from directly managing your database.
  • Authentication of individual users using passwords. This is not absolutely necessary, but it helps to make sure that the right people are accessing your server, and if badguy ever gets someone’s password (or if someone becomes bad), you can revoke their access to the server by disabling them password login.

If you are interested in learning more about how attackers can extract your source code from your apk file, I would recommend looking at these tools:

0
source

Source: https://habr.com/ru/post/1495416/

More articles:


All Articles