SSLSession#getPeerCertificates and resumed TLSv1.3 sessions

[Oleg Kalnichevski]

On Tue, 2018-10-23 at 17:09 -0700, Jamil Nimeh wrote:
> 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.
> 

Hi Jamil

Unfortunately we need a way to deal with SSLEngine based connections as
well. 

Would it not be possible to pull the server certificate chain from the
session cache? While debugging HttpClient code I could see the original
TLS session with the complete certificate chain stuck in the TLS
session cache but I could not find a way to correlate the resumed session with the original one in the cache using the public SSLSession API or even to tell if the session has been resumed for that matter. This however looks plausible from inside SSLSessionImpl class.

Cheers

Oleg

> --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
> >