Unexepected Exception with SSLHandler #13993
Comments
It could also be session resumption that sometimes does, or does not happen. Something to look out for. Netty 4.1.108 had a number of fixes to the TLS related code, so try upgrading and see if it helps. If it doesn't, you'll at least get the latest line numbers in the stack traces. |
|
I tested with last Netty version I found : I still face the issue here is the stack traces : (and for completeness the not related one 👇 ) (tested with java 8, 11, 17)
You're talking about TLS session resumption/abbreviated hanshake ? When a CLIENT_HELLO session ID is not empty, right ? Using wireshark, I checked if one of my test is using Session Resumption and I found only 1. What had you in mind exactly because even if session resumption is used. If client authentication is required then an handshake completion success (abbreviated or full handshake) should still lead to a principal/certificate associate to remote peer ? or I miss something ? |
|
In TLSv1.3 session resumption can also look like a very long pre_shared_key, rather than a session_id. |
|
Currently my tests are about TLSv1.2. |
|
Does the test work if you temporarily switch to the |
|
Actually, all my tests currently pass but I get those exception in log that I can not understand. I can not really use Do you have any idea when an handshake could be successful but there is no principal/certificate for remote peer when using |
|
With I don't know if that scenario comes out as "peer not authenticated" when asking for the principal, if the trust manager did not reject the handshake. |
This also sounds like it could be a test isolation failure. Where there's somehow some mutable state shared between tests that shouldn't be. |
I'm pretty sure that my client send at least 1 certificate in all my tests.
Yep lot of my test execute code where trust manager raise a CertificateException and it seems to works well. This generally lead to a SslHanshakeException which is expected (and no hanshake success)
I understand that you think about that. <parallel>classes</parallel>
<threadCount>1</threadCount>which limits interaction between tests. (all my test about netty are in 1 class) |
|
I did the test about client sending empty cert chain with a trustmanager which allow any certificate but with I get this stacktrace at server side: which seems to be the expected behavior. (Maybe just a little @Override
public void consume(ConnectionContext context,
ByteBuffer message) throws IOException {
// The consuming happens in handshake context only.
HandshakeContext hc = (HandshakeContext)context;
// clean up this consumer
hc.handshakeConsumers.remove(SSLHandshake.CERTIFICATE.id);
T12CertificateMessage cm = new T12CertificateMessage(hc, message);
if (hc.sslConfig.isClientMode) {
if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
SSLLogger.fine(
"Consuming server Certificate handshake message", cm);
}
/// ===> same code is used when we consume client or server certificate
onCertificate((ClientHandshakeContext)context, cm);
} else {
if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
SSLLogger.fine(
"Consuming client Certificate handshake message", cm);
}
/// ===> same code is used when we consume client or server certificate
onCertificate((ServerHandshakeContext)context, cm);
}
}
private void onCertificate(ServerHandshakeContext shc,
T12CertificateMessage certificateMessage )throws IOException {
List<byte[]> encodedCerts = certificateMessage.encodedCertChain;
if (encodedCerts == null || encodedCerts.isEmpty()) {
// For empty Certificate messages, we should not expect
// a CertificateVerify message to follow
shc.handshakeConsumers.remove(
SSLHandshake.CERTIFICATE_VERIFY.id);
if (shc.sslConfig.clientAuthType !=
ClientAuthType.CLIENT_AUTH_REQUESTED) {
// unexpected or require client authentication
// ==> this check seems to be about handling client certificate message so error message seems wrong.
// ==> "unexpected" or "requred" client auth should not lead to same message.
throw shc.conContext.fatal(Alert.BAD_CERTIFICATE,
"Empty server certificate chain");
} else {
return;
}
}I also double check with wireshark that my client Certificate message is really empty (and my server certificate message not)
So it seems it does not. |
(I'm using netty 4.1.107.Final)
I configure
SSLHandlerwithclientAuth(ClientAuth.REQUIRE).And sometime I face this kind of exception :
In my custom code, I try to get remote peer principal but it seems it is null and so raise an
SSLPeerUnverifiedException.But how it is possible, because looking at the stacktrace we can see that this happens on :
To be fully complete, I see this issue in my unit tests sometime but this sounds not really reproductible each time. (Does it smell the race condition ? )
I'm new netty user so maybe I did something wrong. Just in case I put a link to my code : https://github.com/eclipse-leshan/leshan/tree/java-coap-tcp-tls/leshan-tl-javacoap-server-coaptcp/src/main/java/org/eclipse/leshan/transport/javacoap/server/coaptcp/transport
Not directly link but I also face this kind of issue sporadically :
The text was updated successfully, but these errors were encountered: