(3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Xuelei Fan]

On 8/15/2012 12:54 AM, Sean Mullan wrote:
> SSLParameters:
> 
> In your README, you write:
> 
> "Unknown server name type will be expressed as "sni-<integer>", and the
> value of the name is encoded as UTF-8 string."
> 
> This needs to be documented in the APIs.
As we document the known server name types in Java doc. I thought it may
be enough to document unknown ones in java doc also. But I understand
your point if we define constants, SSLParameters.SNI_HOST_NAME.

> I think you should also be more
> specific about what <integer> means - I assume this is the type value in the SNI
> extension?
> 
Yes.

> - It might be useful to add a public String constant for the "host_name" type,
> ex: SSLParameters.SNI_HOST_NAME.
> 
Good point.

> setServerName:
> 
> "In client mode, it is recommended that, by default, providers should include
> the server name indication whenever the server can be located by a supported
> name type."
> 
> If we say "recommended" it means that it isn't a violation of the specification
> if a provider doesn't do this, and that makes it impossible to test compliance
> and harder for apps to depend on consistent behavior across different providers.
> I think we should strongly consider changing "recommended" and "should" to
> "required" and "must" here. Is there any reason why a provider wouldn't want to
> do this?
> 
>From my point, it is mainly for compatibility. Third parties old
providers may not support SNI or may not provider default values. For
example, if the following is an old block of code:

    SSLParameters sslParameters = new SSLParameters();
    sslParameters.setCipheSuites(...);
    ...
    SSLSocket sslSocket =
        sslSocketFactory.createSocket("www.example.com", 443);
    sslSocket.setParameters(sslParameters);

SunJSSE in JDK 7 will have the default value "www.example.com", but
other vendors may not.  So I think if I use a strong tone,
"must"/"required", applications may run into problems with old
providers.  I hope an application specify the value explicit in order to
avoid provider dependency.

Xuelei

> --Sean
> 
> On 8/12/12 8:50 AM, Xuelei Fan wrote:
>> Hi,
>>
>> Please review the spec of JEP 114, TLS Server Name Indication (SNI)
>> Extension.
>>
>>     http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/
>>
>> Please read the README to help you understanding the the specification:
>>
>>    http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt
>>
>> The major differences comparing with previous webrev are:
>> 1. client mode and server mode will use separated API set.
>>    For client, the related APIs are:
>>      setServerName(String type, String value)
>>      clearServerName(String type)
>>      disableServerName(String type)
>>      enableServerName(String type)
>>      isDisabledServerName(String type)
>>      getServerNames()
>>
>>    For server side, the related APIs are:
>>      setServerNamePattern(String type, Pattern pattern)
>>      clearServerNamePattern(String type)
>>      getServerNamePatterns()
>>
>> 2. close the door to use the generated socket in client mode.
>>
>>    SSLSocketFactory.createSocket(Socket s,
>>        InputStream consumed, boolean autoClose)
>>
>>    The returned socket was set in server mode.
>>
>> Regards,
>> Xuelei
>>