How to Override the Cipherlist Sent to the Server by Android When Using Httpsurlconnection

SSL/TLS protocols and cipher suites with the AndroidHttpClient

When using the AndroidHttpClient to make REST requests via HTTPS, how can I specify which SSL protocols and ciphers to use?

I don't believe you can do it with AndroidHttpClient. Everything I've done to harden the channel (like cipher lists, certificate pinning, and public key pinning) required a custom class somewhere, whether it was SSLSocketFactory or X509TrustManager. That's Java and that's Android. See How to override the cipherlist sent to the server by Android when using HttpsURLConnection?.

SSLProtocolException when using HttpsUrlConnection against same server from separate threads

So, to answer the question, yes, that should work. It did not in my old jdk 8 update 102 but it certainly does in an version 8 update 172 one.

I don't really understand the "only second instance affected behavior" but it was certainly related to unlimited strength policy files not present. Setting those up solved the issue.

Now this is not a issue since jdk 8 update 161.

Thanks anyway

Force JVM to use certain Cipher for https connections

This system property only affects the default https client code; not the overall list of ciphers, i.e. anything that uses an HttpsURLConnection would be controlled by the https.cipherSuites value.

It's not particularly well documented - it's in the source of sun.net.www.protocol.https, and it's explicitly called out in the jsse reference guide:

https.cipherSuites system property. This contains a comma-separated list of cipher suite names specifying which cipher suites to enable for use on this HttpsURLConnection.

If you want to override the socket factory in it's entirety, you could create a class to do the same - this answer makes a reasonable attempt.

Using a specific Security Provider in Java

After many hours of research I finally know how to set which provider should be prefered. In the Provider Documentation of Oracle it is mentioned in the section about Installing Providers:

security.provider.n=masterClassName

This declares a provider, and
specifies its preference order n. The preference order is the order in
which providers are searched for requested algorithms (when no
specific provider is requested). The order is 1-based: 1 is the most
preferred, followed by 2, and so on."

Anyway for myself i decided to not implement and register my own provider. It is a hell lot of overhead, really. I guess I will go by securing a socket manually in c++ with OpenSSL or something.

Links you may also find helpfull:

• JuiCE Apache OpenSSL JCE Provider (retired in 2007). You should definitely NOT use their implementation, it is absolutely out of date. But looking at the code will make clear how much work implementing an own provider is. Anyway you would also need a JSSE Provider.

• Sun Provider Source Code, may give you an idea how SUN integrates the crypto functionality (JCE and JSSE Provider)

• OWASP Tutorial for using JSSE - Java Secure Socket Extension. Which shows how to use a provider.

• JSSE Reference Guide with even more usefull information

Edit: You can only be sure that YOUR provider is used if you implement all requested services (or engines) you need in your application. If you make a call for a functionality that is not offered by your service provider java will choose the next available (according to implicit pereference order) service provider which offers the service (and you probably won't notice it).

---

Related Topics