Choosing encryption in SSL

Question

How can I define exactly which encryption I will use in the routine below? I want to define for example that the encryption to be used is the AES, or DES, or 3DES...

// Setup truststore
KeyStore trustStore = null;
trustStore = KeyStore.getInstance("BKS"); 

TrustManagerFactory trustManagerFactory = null;
trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
InputStream trustStoreStream = ctx.getResources().openRawResource(R.raw.truststore);

trustStore.load(trustStoreStream, "MyPassword".toCharArray());
trustManagerFactory.init(trustStore);

// Setup keystore
KeyStore keyStore = null;
keyStore = KeyStore.getInstance("BKS");

KeyManagerFactory keyManagerFactory = null;
keyManagerFactory = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());

InputStream keyStoreStream = ctx.getResources().openRawResource(R.raw.client);
keyStore.load(keyStoreStream, "MyPassword".toCharArray());
keyManagerFactory.init(keyStore, "MyPassword".toCharArray());

ssl_ctx = SSLContext.getInstance("TLS");
ssl_ctx.init(keyManagerFactory.getKeyManagers(), trustManagerFactory.getTrustManagers(),
        null);

Answer 1

Disclaimer: I am not a security expert, nor do I have practical experience with Java TLS. This is a partial answer, intended to assist in the search for a definitive answer.

First, it is worth noting that AES/DES/3DES is only part of the equation: they correspond to a cryptographic primitive for symmetric encryption. Alone, they are useless. So that a "Cipher suite" is composed of several distinct primitives, such as: 1) key exchange method; 2) asymmetric digital signature; 3) symmetric encryption - block; 4) symmetric encryption - operation mode; 5) hash. If you run the code below, for example, you will see which suites are supported (but not necessarily enabled) by your Java:

SSLParameters params = ssl_ctx.getSupportedSSLParameters();
String[] suites = params.getCipherSuites();
for (int i = 0; i < suites.length; i++)
    System.out.println(suites[i]);

Output example (varies by implementation):

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
...
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
...
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
...
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_KRB5_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_NULL_SHA
...

_Source

As you can see, each supported suite can use SSL or TLS, and for the same algorithm (AES_128, for example) others may vary (e.g.: RSA vs. Elliptic Curves, SHA256 vs. SHA vs. MD5, etc). In some cases no algorithm is employed (e.g..: NULL - causes communication not be confidential), in others one is used that is not in your list (ex.: RC4_128 or DES40).

I don’t know how to answer you how to define exactly which of these algorithms to use. If you want to put some of them on a "blacklist", one way is by using the property jdk.tls.disabledAlgorithms, that already comes with some of them disabled by default:

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

_Source

Now, if what you want is a "white list" (e.g., take the array of supported algorithms and filter by those that fit your criteria), you need to find out exactly where in the code you should do this. At first this could be done directly on SSLSocket, since before the handshake (Handshake):

There are two groups of encryption suites you will need to know when managing them:

• Supported suites: all suites that are supported by the SSL implementation. This list is reported using getSupportedCipherSuites.
• Enabled suites, which may be less than the full list of supported suites. This group is assigned using the method setEnabledCipherSuites and recovered using the method getEnabledCipherSuites. Initially, a standard suite set will be enabled on a new socket representing the minimum configuration suggested.

Implementation standards require that only suites that authenticate servers and provide confidentiality are enabled by default. Only if both sides explicitly agree to communications without authentication and/or private (no encryption) will such a suite be selected.

When Sslsockets are initially created, no handshake is done so that applications can first assign their communication preferences: which suites to use, whether the socket should be in client mode or server mode, etc. However, security is always guaranteed at the time when application data is sent via connection.

This suggests that this property can be assigned directly to SSLSocket. That answer on Soen seems to agree with this, but I cannot give assurances as to its correctness (in particular, it is important to know whether the handshake has already happened or not - and I do not know how to do that, or even if it is possible).

Another possibility is to use the SSLParameters who receives a list of suites. Where to use these parameters, also can not tell you (as already said, I have no practical experience in the subject). It may be in the socket itself (through setSSLParameters - in that case, it is the same exception as the other suggestion above), or perhaps require the creation of a SSLSocketFactory custom, etc...