OCSP Stapling support and guidance on use of JDK Provider

[nycnewman]

The current security guidance on use of TLS Provider emphasises BoringSSL. Based on testing BoringSSL does not support OCSP Stapling so connections suffer performance issue if certificate revocation checking is a requirement.

Is the Security.md guidance still up to date now that JDK 11 (whether from Oracle or AdoptOpenJDK) support OCSP Stapling and other required protocols (APLN)? Is JDK still considered suboptimal for grpc-java use?

[voidzcy]

OCSP stapling should work out-of-the-box for JDK 11 and netty-tcnative. That's considered to be a sub item for TLS. Security.md is mostly an instruction of the basic setup for users using TLS with gRPC. Users are free to use available TLS configurations from each provider.

[nycnewman]

Thank you. I have been able to demonstrate OCSP Stapling with JDK Provider by specifically requiring JDK Provider as part of TLS configuration. My question is really around whether there is any reason or consequences to switch from BoringSSL to JDK, i.e. performance , security vulnerabilities, capabilities, etc. BoringSSL appears to not support OCSP Stapling but I'm guessing that there may be other aspects that need to be considered as part of this choice. The Security.md documentation does talk to this.

[voidzcy]

@ejona86 Could you share your knowledge/experience of different TLS implementations between JDK and BoringSSL? We'd
really appreciate it.

[ejona86]

BoringSSL appears to not support OCSP Stapling

Why do you said that? Does it just "not work." That is probably deserving of a bug with Netty. @voidzcy provided evidence that it appears to support OCSP stapling, so it seems like they'd expect it to work. We don't have experience configuring OCSP stapling though.

Using JDK 11 for security is fine if it works for you. On some platforms it is necessary. gRPC Java still supports Java 7 and JDK 7's AES-GCM is glacially slow and it doesn't support ALPN. Java 8's AES-GCM is still significantly slower than boringssl, but many users may be able to accept the performance decrease now that it supports ALPN. Java 11 is pretty close, but I've not done recent benchmarking.

[nycnewman]

Appreciate the insights. Despite spending quite some time I couldn't figure out the correct incantation to get BoringSSL to respond to OCSP extension requests. I was quite quickly able to get JDK to work. Thus question about current guidance on which is the recommended version. Useful to hear that Java 8 is slow. I'll look again at BoringSSL to see whether I missed something. Cheers

[ejona86]

Did you see the example? https://github.com/netty/netty/blob/4.1/example/src/main/java/io/netty/example/ocsp/OcspServerExample.java It uses OPENSSL as the provider.

I suggest filing an issue on github.com/netty/netty and CCing me on it just in case there's something we do in gRPC that defeats your configuration.

To give throughput numbers as I remember them (from many a year ago). IIRC these were just raw AES-GCM encoding speed when saturating a core:
Java 7 - 2 MB/s
Java 8 - 20 MB/s
Java 8u60 - 200 MB/s
tcnative - 1000 MB/s

[ejona86]

Looks like there's nothing more for us to do with this at the moment. If there's new information pointing out how OCSP with tcnative is broken after looking at the example that'd be good to share and we could then look into it more. If there's any other details, comment and we can reopen.