Code Review Request 8144566, Custom HostnameVerifier disables SNI extension

[ecki at zusammenkunft.net]

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.wetmore at oracle.com>
To: Xuelei Fan <xuelei.fan at oracle.com>, OpenJDK <security-dev at 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
>