Design/Architecture of netty's handler/ssl package?

Question

I've been looking somewhat closely at the netty handler/ssl package: https://github.com/netty/netty/tree/4.1/handler/src/main/java/io/netty/handler/ssl

I've noticed that it depends on a handful of external projects to do the actual work of SSL, and I'm trying to make sense of how they all fit together. Here's what I've uncovered (so far):

• BouncyCastle (for self-signed certs?)
• Jetty (for ALPN?)
• TC Native (for OpenSSL/BoringSSL-based SSLEngine?)
• Conscrypt (for also OpenSSL/BoringSSL-based SSL stuff?)

How do all these pieces fit together? I notice that lots of the deps to these in the pom.xml are marked as optional, so its unclear which of these dependencies are mutually exclusive.

For instance, I can tell that Conscrypt and one variant of TC Native would both link in static versions of BoringSSL which is considered a no no, so does that mean in practice you'd only depend on Conscrypt OR TC Native? Also, I couldn't figure out what part of jetty provides the ALPN code that is being used.

Is there an area of the Netty website that has detailed design docs for aspects of the system like this? Wondering how one learns the design of this large open source project other than just ambling about in the code.

Thanks!

Answer 1

BouncyCastle is for self-signed certs and similar; the dependency is easy to avoid. Jetty ALPN, netty-tcnative, and Conscrypt are all optional; you don't have to use any of them.

Jetty ALPN modifies the OpenJDK source to add ALPN support to Java's TLS implementation. This is really only needed when doing HTTP/2. You can enable Jetty ALPN with the Jetty ALPN Agent .

Netty-tcnative and Conscrypt also provide ALPN support. But they are also much faster, especially when using AES GCM. They are wrappers on OpenSSL, LibreSSL, or BoringSSL, so replace the Java TLS implement with the same library already used in many other languages. This can also bring new security features to Java.

You noticed there are static versions that include BoringSSL; this allows easily running on Windows and OS X, which don't have (up-to-date) OpenSSL, as well as bringing newer TLS features (like ALPN) to Linux distributions like Debian. And this is really useful for more traditional applications where the user is a different party than the developer.

Conscrypt has existed on Android for quite a while, but it pretty new to OpenJDK and the Netty support is thus also very new. For the short-term, netty-tcnative would be preferred over Conscrypt. That could change rapidly though.

If you're using HTTP/2, then knowing about Jetty APLN vs Netty-tcnative vs Conscrypt is important. But most people end up just wanting better performance or a certain TLS feature unsupported by Java's implementation and so begin using netty-tcnative.