SSLSession#getPeerCertificates and resumed TLSv1.3 sessions
Jamil Nimeh
jamil.j.nimeh at oracle.com
Wed Oct 24 00:09:33 UTC 2018
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
>
More information about the security-dev
mailing list