(3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension (original) (raw)
Xuelei Fan xuelei.fan at oracle.com
Mon Aug 13 09:25:21 UTC 2012
- Previous message (by thread): (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension
- Next message (by thread): (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 8/13/2012 11:34 AM, Weijun Wang wrote:
511 * If a server name type is not contained in the returned
Map
, 512 * an SSL/TLS handshaking should not be interrupted for reasons of 513 * unrecognized server name of that type.Is this only Oracle JSSE behavior? Or every vendor should do that? Of course, I have no good idea how a server can get a default pattern. It's the required behavior for all providers. According to TLS extensions spec, a server run into unknown extensions, it should ignore the extension and continue the transactions. And for compatibilities, a server also should ignore the SNI extension. So I would like it to be a behavior of all providers.
SSLSocketFactory.java: 202 * 203 * Please NOTE that the application is responsible for ensuring that this 204 * method must be called before any handshaking occurs, and all 205 * consumed network data must be resumable from the
consumed
206 * parameter. Otherwise, the behavior of the returned socket is not 207 * defined.I think the precise meaning of "any handshaking occurs" is "any bytes is sent back to client"? Yes, I will do dome word smithing here.
Thanks, Xuelei
- Previous message (by thread): (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension
- Next message (by thread): (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]