Hello Oleg,
Thanks for bringing this to our attention. I've filed JDK-8212885 to
track this issue. I haven't played around with my test code to look for
alternative ways to get at the peer cert chain, but I can try a few
things. I have one idea but it is completely a shot from the hip since
I haven't had time to try it. I'll throw it out there anyway while I
experiment with it. For SSLSocket based connections there's a
HandshakeCompletedListener that can be registered with the socket. That
listener object takes a HandshakeCompletedEvent which in turn has access
to the socket and the session. Perhaps at the completion of the initial
handshake those peer certificates could be pulled from the
HandshakeCompletedEvent. That class has its own getPeerCertificates()
method and can also give you the session object and a few other pieces
of data that are found in the SSLSession object like the cipher suite,
etc. If your listener can do something with the HandshakeCompletedEvent
that you'd (hopefully) get at the end of the initial handshake then
perhaps you can obtain the cert chain that way.
Like I said, I'm not sure this will work having not tried it yet (but I
will). I'll let you know if I can come up with a concrete workaround
while we're getting the issue fixed.
--Jamil
P.S. JBS: https://bugs.openjdk.java.net/browse/JDK-8212885
On 10/21/18 1:31 PM, Oleg Kalnichevski wrote:
Good time of the day
OpenJDK 11 TLS v1.3 implementation at present breaks hostname
verification code in all versions of Apache HttpClient and I am trying
to figure the best way to remedy the situation.
Resumed TLS v1.3 sessions do not appear to carry a server certificate
chain, which, is as far as I understand, is to be expected. In case
of resumed TLSv1.3 sessions an attempt to get the servers certificates
with SSLSession#getPeerCertificates causes "peer not authenticated"
SSLPeerUnverifiedException. The trouble is that I fail to see any way
to find out whether or not an TLS v1.3 session has been negotiated
using the complete TLS handshake or resumed.
The only solution I was able to have found so far is to catch
SSLPeerUnverifiedException, see if the TLS protocol is v1.3 and presume
this is because the session has been resumed [1]. This naturally looks
and feels very dodgy.
Please advise how one should tell if TLS v1.3 session has been resumed
using SSLSession interface or what would be the right way to perform
hostname verification or any custom certificate validity checks with
TLS v1.3.
Thank you in advance
Oleg Kalnichevski
[1]
https://github.com/ok2c/httpclient/commit/6ca28be047a7a461c7814ee7e0f3e083158ee349
