-
Couldn't load subscription status.
- Fork 654
Fixing test assertions for TLSv1.3 #937
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Thanks @the-thing , will have a look! 👍 |
|
We could also add I forgot to mention that this will work for TLSv1.2 as well... |
I'll leave that up to you. Thank you |
|
Please let me know when this is ready to merge. |
|
It is ready, but some other test have failed.
I see the acceptance test suite failing occasionally here and there. |
I'm sure it does not have to do with your changes. One of the acceptance tests fails from time to time, did not have time to follow up. |
This will fix the SSL test suite for TLS v1.3.
Changes
SSLCertificateTest(see TLSv1.3 test #892)assertNotAuthenticatedmethodThe problem with authentication and TLS v1.3 seems to be with MacOS Java version 8 and 11 as it fails continuously with this combination (works fine with MacOS Java 17). I've seen it failing occasionally on Ubuntu.
The authentication actually works fine, but the assertions were not correct. Seeing
Certificate was authenticatedwas misleading since the previous checks -assertSslExceptionThrownandassertNotLoggedOnwere successful, which means that SSL session was actually NOT established with invalid certificates as expected.Even when authentication is enabled and SSL handshake fails, the peer certificates (and peer principal) are set for
javax.net.ssl.SSLSession#getPeerCertificates(there is a note in later versions of Java > 8 in JavaDoc forgetPeerCertificatessaying Note: The returned value may not be a valid certificate chain and should not be relied on for trust decisions.). This means that we can't rely on the value there.It seems that peer certificates and peer princpial are set for all SSL sessions that require authentication regardless if the check was successful or not. Only when auth is disabled e.g by setting
javax.net.ssl.SSLParameters#needClientAuthto false these certificate chains and peers can be expected to be empty.For authentication we have to rely on MINA removing the
org.apache.mina.filter.ssl.SslFilterfromorg.apache.mina.core.session.IoSessionfilter chain.Putting a few second delay after initiator start solves the problem as it is enough for MINA to tear down the SSLFilter - that's what I did, but with busy spin loop. I also kept the old validation code for peers that don't require auth.