TLS negotiation continues with optional client authentication when a client has a bogus certificate with Netty 4.1.7 and a native SSL provider

After upgrading to Netty 4.1.7, I’ve observed that Netty SSL clients can connect to Netty SSL servers that require client authentication even if they present a certificate that is not trusted by the server.

Steps to reproduce

1. Create an SSL server with an SslHandler that requires client authentication and a trust chain that contains a single root certificate.
2. Create an SSL client with an SslHandler that will present a randomly-generated client certificate (i.e. definitely not in the server’s trust chain).
3. Connect the client to the server.

Expected behavior

The server rejects the connection attempt (or at least fails the handshake attempt) because client authentication is required and the client has presented a certificate that is not trusted by the server. This was the behavior in Netty 4.1.6 and earlier.

Actual behavior

The connection attempt succeeds without error as of Netty 4.1.7.

Minimal yet complete reproducer code (or URL to code)

Minimal test case pending. In the interim, I offer ApnsClientTest#testConnectWithUntrustedCertificate.

Netty version

4.1.8 (using both the JDK and OPENSSL SSL providers)

JVM version

$ java -version
java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16, mixed mode)

OS version

$ uname -a
Darwin stratus.local 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64

[jasontedor]

I can’t say what is going on here, but I investigated this, and we are not impacted by it.

That said, I think that the Netty project needs a responsible disclosure policy for issues like this. If there is any truth to this issue at all, it would have been better if it not be disclosed in the open until a fix is available and downstream projects have an opportunity to react.

I poked around the docs looking for a responsible disclosure policy. Is there one that I missed @normanmaurer? If not, can you please formulate one and communicate it clearly? I would be happy to open a separate issue for this.

[Scottmitch]

Would you still like me to verify the certificates count thing? If so, can you clarify where you were looking?

Yes. Use some network analyzer (tcpdump, Wireshark) to inspect the handshake data. Wireshark can actually analyze the packets and understands the SSL/TLS handshake and gives you a nice GUI (which is the screenshot above). What I want to verify is the ServerHello includes the CertificateRequest and the client’s response includes an empty certificate list (list shown above). Under these conditions (optional authentication) it is expected that the handshake succeeded.