RFR JDK-8211806: TLS 1.3 handshake server name indication is missing on a session resume

[Jamil Nimeh]

Yes, in fact I'm building the test now.  Sorry, I got a bit 
trigger-happy on getting the fix in place and forgot to cook up the test 
for it!  So there will be a .02 version coming shortly.

In terms of testing, I think I found a way without having to do virtual 
servers and can even bypass sockets and use engines instead.  My plan is 
to set up the client with a made-up server name a la 
SSLParameters.setServerNames.  Then on the server side set a matcher 
that explicitly checks for that name only.  When the session gets 
resumed, the extension should be missing and cause an error.  With the 
patch it should be there and things should pass.

At least that's my working theory.  Hopefully it will pan out.

--Jamil


On 10/15/2018 08:36 AM, Bradford Wetmore wrote:
> Jamil,
>
> Do you have an idea for a unit test?  Are there any test servers that 
> can do virtual server in our suites?  (e.g. return certs based on 
> their server_name?)
>
> Otherwise, I'd to do a quick double check of a couple things in the 
> code, but initially it looks ok.
>
> Brad
>
>
> On 10/12/2018 9:39 PM, Jamil Nimeh wrote:
>> Hello all,
>>
>> This addresses an issue where the client hello in a resumed TLS 1.3 
>> session lacks the server_name client hello extension.  This can cause 
>> servers who use this extension field to direct traffic to websites to 
>> present other certificate chains for other websites than the one the 
>> client actually desires (and specified in the original client hello 
>> where the extension is present).
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8211806
>>
>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8211806/
>>
>> Happy Friday!
>>
>> --Jamil
>>