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




Reply via email to