(2nd round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Xuelei Fan]

This paragraph was removed in the latest update. Please ignore the
webrev_spec.04 and previous webrevs, and review webrev_spec.05.

http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.05/

Thanks,
Xuelei

On 8/15/2012 3:24 PM, Bradford Wetmore wrote:
> 
> 
>>> How would the ServerHello be generated until you call this method and
>>> then start the handshaking on the returned SSLSocket?
>> One can use SSLEngine.wrap()/unwrap() to generate handshaking messages
>> from socket I/O stream.
>>      // accept a socket
>>      // read/write the I/O with SSLEngine
>>      // call this method
> 
> Switching between SSLSocket/SSLEngine like that would require
> intentional misuse of the API.  You could make the same claim for
> regular handshaking.
> 
> Brad
> 
>> Xuelei
>>
>>> You said in a
>>> previous internal conversation that SSLExplore would not generate any
>>> ServerHello, so this can't be what you mean.  Are you talking about
>>> layering another SSLSocket over a already layered SSLSocket?
>>>
>>>>> 2. "consumed network data is resumable" wasn't clear either.  To me
>>>>> this
>>>>> should mean that you can obtain the data which has already been read
>>>>> from "s".
>>>>>
>>>> Yes, need wordsmithing here.
>>>>
>>>>> 3. "Otherwise, the behavior of the return socket is not defined" lost
>>>>> me.  Does this mean that that SSLParameters and assorted settings are
>>>>> not otherwise defined?
>>>>>
>>>> See above example.
>>>
>>> I think I need the above answered before I can comment further here.
>>>
>>>>> I think you could delete this paragraph.
>>>>>
>>>>>   From your second email:
>>>>>
>>>>>> Thought more about the design, I would have to say that we cannot
>>>>>> return
>>>>>> the default value in sslParameters.getServerNames().  Otherwise, the
>>>>>> following two block of codes look very weird to me:
>>>>>>        // case one:
>>>>>> 1   SSLparameters sslParameters = sslSocket.getSSLParameters();
>>>>>> 2   sslParameters.clearServerName("host_name");
>>>>>> 3   Map<String, String> names = sslParameters.getServerNames();
>>>>>> 4   sslSocket.setSSLParameters(sslParameters);
>>>>>> 5   sslParameters = sslSocket.getSSLParameters();
>>>>>> 6   names = sslParameters.getServerNames();
>>>>>>
>>>>>> In line 3, the returned map does not contain "host_name" entry.
>>>>>> But in
>>>>>> line 6, it may be expected that no "host_name" in the returned
>>>>>> map. But
>>>>>> if we want to return default values, line 6 do need to return a map
>>>>>> containing "host_name".  The behavior is pretty confusing. We may
>>>>>> want
>>>>>> to try avoid the confusion.
>>>>>
>>>>> I'm not following your confusion, it seemed pretty straightforward to
>>>>> me, it works much like CipherSuites.  We have a set of ciphersuites
>>>>> which are enabled by default.  We can turn some off by using
>>>>> SSLParameters.  Expanding a bit on your example here, I'll describe
>>>>> what
>>>>> I think would happen internally/externally:
>>>>>
>>>>> 1    SSLSocket sslSocket = mySSLSocketFactory.createSocket(
>>>>>           "www.example.com", 443);
>>>>>
>>>>> mySSLSocketFactory sets any initial parameters as usual. 
>>>>> SSLSocketImpl
>>>>> knows it's connecting to www.example.com and automatically stores
>>>>> "host_name" -> "www.example.com" in its local host data (map or
>>>>> separate
>>>>> variables).
>>>>>
>>>>> 2   SSLparameters sslParameters = sslSocket.getSSLParameters();
>>>>>
>>>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, and sets the
>>>>> hostmap to the one value "host_name" -> "www.example.com"
>>>>>
>>>>> If the application want to get the "default values", they just pull
>>>>> them
>>>>> out of the SSLParameters here
>>>>>
>>>>> 3   sslParameters.clearServerName("host_name");
>>>>>
>>>>> Or sslParameters.setServerName("host_name", null)?
>>>>>
>>>>> User just decided to clear it.  Ok, that's what we do.  It becomes an
>>>>> empty map in SSLParameters.
>>>>>
>>>>> 4   Map<String, String> names = sslParameters.getServerNames();
>>>>>
>>>>> Returns empty Map.
>>>>>
>>>> As far as good.
>>>>
>>>>> 5   sslSocket.setSSLParameters(sslParameters);
>>>>>
>>>>> SSLSocketImpl.setSSLParameters is empty, so SSLSocketImpl takes this
>>>>> SSLParameters and as a result, clears it's internal "host_name" map to
>>>>> null, and thus won't send anything out since it's empty.
>>>>>
>>>> We have problems here.  We need to support that if an application does
>>>> not specified host_name value, we should use default values.
>>>>     I.   SSLParameters sslParameters = new SSLParameters();
>>>>     II.  sslParameters.setCipherSuites(...);
>>>>     III. SSLSocket sslSocket =
>>>>             sslSocketFactory.createSocket("www.example.com", 443)
>>>>     IV.  sslSocket.setSSLParameters(sslParameters);
>>>>
>>>> Before line IV and after line II, the sslParameters.getServerNames()
>>>> are
>>>> empty. In line IV, we need to make sure the internal "host_name",
>>>> "www.example.com" is used as default value, and send it to server in
>>>> SNI.  That's the default behaviors in JDK 7.  We cannot break it
>>>> without
>>>> strong desires.
>>>>
>>>> I think it means that we cannot clear the internal "host_name" when the
>>>> sslParameters.getServerNames() return empty.
>>>>
>>>> Does it make sense to you?
>>>
>>> Ok, that's an issue, I was assuming people would generally get a
>>> SSLParameters from the SSLSocket/SSLEngine, which would have
>>> prepopulated values such as CipherSuites/Protocols and SNI values. Now I
>>> hear what you're saying.
>>>
>>> So in SSLSocket/SSLEngine, we have a very similar situation with the
>>> CipherSuites/Protocols.  The way we did it there was if
>>> SSLParameters.getCipherSuites() is null (that is, has not been set in
>>> this instance), we let the default values stand (that is we did not call
>>> SSLSocket.setEnabledCipherSuites()).  You could do something like that
>>> with the SNI info.  I've always felt the setServerName/getServerName
>>> should take/return the same Map<String,String> value, but you felt
>>> strongly about a setServerName(String, String) so I didn't push it.  If
>>> we didn't set this value, then the original value could stand.
>>>
>>> Maybe your current design addresses this in a better way, I'll have to
>>> look at this in the morning, I still have a couple hours of home stuff
>>> to do before I can go to bed.
>>>
>>> Brad
>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>>> 6   sslParameters = sslSocket.getSSLParameters();
>>>>>
>>>>> SSLSocketImpl.getSSLParameters() creates a SSLParameters, which sees
>>>>> that there's no name indication, so it creates an empty name map and
>>>>> stores in SSLParameters.
>>>>>
>>>>> 7   names = sslParameters.getServerNames();
>>>>>
>>>>> returns empty.
>>>>>
>>>>> It's no longer the default value, because they have specifically
>>>>> set the
>>>>> value.
>>>>>
>>>>> HTH,
>>>>>
>>>>> Brad
>>>>
>>>
>>
>