Use netty 4.1+ TLS with Android 6

My project currently uses a modified version of 4.0.28.Final which runs on Android 6.0.1. The diff is basically removing all classes which are not existent on Android 6.0.1 to be able to compile netty as a shared library for our Android build. To use TLS with the parameters needed we construct the SSLEngine ourself and hand it over to the netty SslHandler(SSLEngine engine).

We wanted to upgrade netty to 4.1.28.Final which has better Android support and tons of fixes regarding TLS compared to version 4.0.28.Final. Since we are using Android 6.0.1 with Conscrypt/BoringSSL the constructed SSLEngine is a org.conscrypt.OpenSSLEngineImpl.

Expected behavior

When we init SslHandler() with org.conscrypt.OpenSSLEngineImpl we expect SslHandler to detect the given SSLEngine to be a SslEngineType.CONSCRYPT.

Actual behavior

SSLHandler will fallback to SslEngineType.JDK due to:

engineType = SslEngineType.forEngine(engine);

which calls

static SslEngineType forEngine(SSLEngine engine) {
    return engine instanceof ReferenceCountedOpenSslEngine ? TCNATIVE :
    engine instanceof ConscryptAlpnSslEngine ? CONSCRYPT : JDK;
}

I also noticed PlatformDependent0.javaVersion0() will set to

if (isAndroid0()) {
    majorVersion = 6;
} 

but Android 6.0.1 will provide Java 1.7.

Steps to reproduce

SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
sslContext.init(kmf.getKeyManagers(),tmf.getTrustManagers(), new SecureRandom());
SSLEngine sslEngine = sslContext.createSSLEngine();
sslEngine.setUseClientMode(true);
SslHandler sslHandler = new SslHandler(sslEngine);
channel.pipeline().addFirst(sslHandler)

Minimal yet complete reproducer code (or URL to code)

N.A.

Netty version

netty-4.1.28.Final

JVM version (e.g. java -version)

SDK API-level 23 Java 1.7

OS version (e.g. uname -a)

Linux localhost 4.4.111-1.1.1 #14 SMP PREEMPT Wed May 16 01:39:17 CEST 2018 armv7l

[gnarea]

See also #10181

[normanmaurer]

@selop so I did some digging and I think the problem here is that Android uses a “different conscrypt” implementation than what we use here. So I think it is not really “that” easy. Can you tell me what problem you have because of the current implementation ? I think even with JDK it should “just work”.

/cc @nmittler @ejona86 @carl-mastrangelo