Isnt this codepath used as a workaround for dynamically disabling SNI? Using connect(host..) instead of SSLSocket(host) was at least a common, well known workaround.
Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Bradford Wetmore <bradford.wetm...@oracle.com> To: Xuelei Fan <xuelei....@oracle.com>, OpenJDK <security-dev@openjdk.java.net> Sent: Di., 08 Dez. 2015 2:51 Subject: Re: Code Review Request 8144566, Custom HostnameVerifier disables SNI extension Please see my comment in the bug. I haven't verified this, but it seems the problem might be generic to the codepath through SSLSocket, not just Https. Brad On 12/6/2015 4:32 AM, Xuelei Fan wrote: > Hi, > > Please review the update for JDK-8144566: > > http://cr.openjdk.java.net/~xuelei/8144566/webrev.00/ > > For HttpsURLConnection, the server name may be set after the TLS > connection and handshake has been initialized. As may result in that > the server name does not present at TLS ClientHello messages. > > This fix resets the server name for the initialized handshake for above > cases. > > Thanks, > Xuelei >
