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
