Add Conscrypt for native ALPN/TLS/SSL

[jmcc0nn3ll]

migrated from Bugzilla #470848
status ASSIGNED severity enhancement in component http2 for 9.3.x
Reported in version unspecified on platform All
Assigned to: Greg Wilkins

On 2015-06-23 17:47:12 -0400, Louis Ryan wrote:

Full disclosure: I work on GRPC for Google and we have been using the ALPN/NPN bootclasspath mechanism for a while but are planning to switch to tcnative (specifically http://netty.io/wiki/forked-tomcat-native.html)

This change is motivated by a number of factors:

• Its proven hard to get client developers to properly set their bootclasspath based on their VM. It's been a pain with Maven and other harness-like environments too.
• SSLEngine has poor performance for many of the ciphers mandated by HTTP2 E.g. (https://bugzilla.redhat.com/show_bug.cgi?id=1135504)
• Our benchmarking has shown that a properly compiled pairing of tcnative and openssl outperforms SSLEngine on all ciphers.
• We need to be able to support a transparent fallback from ALPN to NPN when talking to servers that are restricted to using OpenSSL 1.0.1 or earlier (all current releases of Debian and RedHat do not yet have 1.0.2 available on stable). NPN bootclasspath is not supported for JDK1.8 and you cant have both Jetty-ALPN and Jetty-NPN installed at the same time.

Not sure if this is something you've looked into or talked about so I just wanted to make sure it was on your radar

Cheers

• Louis

On 2016-01-26 14:57:03 -0500, Louis Ryan wrote:

Just an update on work occurring in this area

netty-tcnative now statically links boringssl and will likely soon also provide options for a statically linked libressl & openssl for linux/mac/windows

netty/netty-tcnative#89 (comment)

This should fix its remaining installation overheads (e.g. dependency on modern shared openssl to be present in the environment)

This will also address Java7s lack of GCM ciphers (http2 required) and Java8s GCM performance issues which seem unlikely to be fixed until Java9.

There's also some ongoing discussion about doing the same with Androids JCE/JSSE provider Conscrypt which is licensed under Apache 2.

https://android.googlesource.com/platform/external/conscrypt/

On 2016-01-27 15:12:25 -0500, Jesse McConnell wrote:

Greg, circle up with me on this one!

On 2016-02-03 06:24:56 -0500, Greg Wilkins wrote:

We implemented Unix domain socket support for similar reasons. I did look at tcnative at the time but it was a little entangled.

The forks linked in this issue look a lot more usable and the drop in replacement of ssl engine should make this almost trivial to integrate with most work going into the pom and modules.

So worthwhile giving this a try in 9.4.

[louiscryan]

Related netty/netty-tcnative#114

Released artifact http://search.maven.org/#artifactdetails%7Cio.netty%7Cnetty-tcnative-boringssl-static%7C1.1.33.Fork13%7Cjar

[louiscryan]

@normanmaurer
@nmittler

[gregw]

@louiscryan Do you know how tcnative and/or borringssl and/or conscrypt deal with direct buffers?

Ie if they are passed direct buffers as either a source and destination buffer, will the encryption be done buffer to buffer or will it be copied back into a heap buffer?

[normanmaurer]

No copy will happen

Am 22.02.2016 um 13:10 schrieb Greg Wilkins notifications@github.com:

@louiscryan Do you know how tcnative and/or borringssl and/or conscrypt deal with direct buffers?

Ie if they are passed direct buffers as either a source and destination buffer, will the encryption be done buffer to buffer or will it be copied back into a heap buffer?

—
Reply to this email directly or view it on GitHub.

[gregw]

@normanmaurer Thanks! that in itself is a very good reason to support tcnative (and/or conscrypt ). I'll do some experiments this week

[normanmaurer]

@gregw that said I only spoke for tcnative... I have not idea about conscrypt.

[gregw]

Ah - I was fooled by the familiar names! SslSession is a totally different class to the JVMs SslSession. To use tcnative will be considerable work.... but it is probably still worth looking at. Will take me a while longer.

[normanmaurer]

We have a full OpenSslEngine impl here:

https://github.com/netty/netty/blob/4.1/handler/src/main/java/io/netty/handler/ssl/OpenSslEngine.java

Am 22.02.2016 um 18:35 schrieb Greg Wilkins notifications@github.com:

Ah - I was fooled by the familiar names! SslSession is a totally different class to the JVMs SslSession. To use tcnative will be considerable work.... but it is probably still worth looking at. Will take me a while longer.

—
Reply to this email directly or view it on GitHub.

[gregw]

@normanmaurer thanks for that pointer - basing our work of that will save a lot of effort... but it still needs a bit of adapting - specially with the buffer and certificate management side of things.

[gregw]

So conscrypt has an OpenSslEngine impl also, similar to the Netty one. While I note that neither does gather writes, I do see that the netty/tcnative impl is using the direct buffers, while conscrypt is copying data to a byte[]. This might be fine for an android device, but is a non-starter for the server side.

[nmittler]

@kruton (for Conscrypt)

Kenny, an thoughts on #215 (comment)?