TLS v1.2 is not working on KitKat.

[inazaruk]

If one is trying to use a slightly stricter ConnectionSpec than MODERN_TLS by limiting TLS to only v1.2 then OkHttp doesn't work on Android KitKat. Even though this version of Android does support TLS v1.2 (https://developer.android.com/reference/javax/net/ssl/SSLSocket.html).

Example:

OkHttpClient will fail to establish connection on KitKat using this spec:

 new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
      .tlsVersions(TlsVersion.TLS_1_2)
      .build();

The underlying problem is that ConnectionSpec is checking if SSLSocket.getEnabledProtocols() contains TLS v1.2 before actually calling setEnabledProtocols() with TLS v1.2. Instead it should check if SSLSocket supports TLS v1.2 and then enable this protocol if so.

It looks like replacing getEnabledProtocols() with getSupportedProtocols() in ConnectionSpec.isCompatible() and ConnectionSpec.supportedSpec() can fix it.

[swankjesse]

@nfuller we’ve got another situation where OkHttp & the host OS disagree. Any idea why TLS 1.2 isn’t enabled on KitKat ?

[nfuller]

IIRC, same situation as with the ciphers: according to http://developer.android.com/reference/javax/net/ssl/SSLSocket.html TLSv1.1 and TLSv1.2 were supported but not enabled.

OkHttp doesn't enable disabled protocols in case the OS "knows better" - e.g. I think SSLv3 may be supported/not enabled and (I'm not a security expert but I think) we wouldn't really want to turn it automatically on because of the security implications.

Clearly an app could (probably should) use TLSv1.1 / TLSv1.2, but from the callers perspective it can't know whether it's supported / disabled because it's new, or because it's obsolete. AFAIK there wasn't any problems with them on KitKat.

I wonder if OkHttp should have some flag on each protocol to flip between "use if enabled" or "use if supported". Maybe I've been lucky/unlucky with timing but I've seen more ciphers being broken/being enabled than protocols in the last 2 years that I've been involved with this kind of thing. For protocols it may make more sense to "use it if you can" on the top end (e.g. TLSv1.1 and TLSv1.2).

It has been discussed before but OkHttp could also have a general flag for "okhttp knows best" (for app usecases where app developers are confident they are going to keep releasing their app code and understand the implications) and "common denominator mode" (for safe / OS embedded scenarios) where the code can find itself on new devices or against new SSL stacks with better information. The flag would determine whether to observe "supported" or "enabled" protocols. Optionally, duplicate everything I said for ciphers.

On Android one way to avoid this whole thing is to use the Google Play Services dynamic security provider: then you get a more up to date SSL stack with TLSv1.2 enabled.

[swankjesse]

Thanks @nfuller. One other catch is that a TLS version might be disabled because it’s buggy.

[faramund]

Same problem. Here is a solution:
http://blog.dev-area.net/2015/08/13/android-4-1-enable-tls-1-1-and-tls-1-2/
This is a hard change, but some payment providers require TLSv1.1 or TLS1.2 now or in next months (PCI-DSS regulations about credit cards), so it is important to enable communications also for 4.4 devices (in theory TLSv1.2 should works also on 4.1).

[swankjesse]

Sadly no action for us to take here. TLS 1.2 is disabled by default on KitKat, and our policy is to use only TLS versions that are enabled by default.