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

Weijun Wang weijun.wang at oracle.com
Wed Aug 15 15:05:19 UTC 2012

4. I just noticed that the type can be also "sni-". What if someone call setServerName("sni-0", "...")? Is it the same as calling setServerName(SNIHOSTNAME, "...")? Unspecified behavior. Maybe not, because of the value encoding method. We may throw exception in Oracle provider. Other providers may want to support "sni-32" or "principal" for its private server name type. I'm not sure. Suppose tomorrow the type nickname(1) is supported and a customer begins using "sni-1". The day after tomorrow, Java is updated and we have a string "nickname" for it. I guess you will make "sni-1" and "nickhome" equivalent so that the customer's app will still work? If so, why not start doing it today for "sni-0" and "hostname"?

In fact, I don't quite understand how this is used. On the client side, when the developer knows nick_name(1) is not yet supported by the current JDK, he will use the "sni-1" type so that the SNI will be correctly encoded. Then, JDK is updated and the name type is now "nick_name", but I believe the old app should still work, so "sni-1" should be still accepted and be equivalent to "nick_name".

On the server side, the old JDK and new JDK would return different values for getServerNames(). It's likely that the user app will be broken if it cannot successfully predict the "nick_name" name and already support it.

Therefore, seriously, I suggest we change Map<String,String> to Map<Integer,String>. Since we already defined SSLParamters constant for the types, the user won't feel uncomfortable.

Thanks Max

More information about the security-dev mailing list