Code review request, CR 7174244, NPE in Krb5ProxyImpl.getServerKeys()

Steven Read at
Wed Jun 20 08:19:17 PDT 2012

Xuelei Fan < at ...> writes:

> Hi Steven,
> JSSE is a provider based framework.  And compatibility is one of the
> most important facts users concerns.  That's to say, a provider
> developed for JDK 6 is expected to work with JDK 7.  As implies that
> sometimes, we cannot changes the specification for some certain cases.
> Otherwise, we would run into compatibility issues. For this case, we did
> not require supported cipher suites are ordered. Providers may not
> implemented to support sorted supported cipher suites. If we update the
> spec to require to sort supported cipher suites in preference, we would
> face the compatibility issue, and the old providers would not be able to
> be used any more. So IMHO, unless there is very very strong concerns, we
> are just not able to update the specification.
> The preference order is an option of JSSE providers. Although it is not
> specified in API specification, SunJSSE providers would like to keep the
> behaviors consistent between different releases. SunJSSE provider
> defined the preference since 1.4.2 or earlier. But the preference may be
> changed in different builds or releases. You may find that
> "SSL_RSA_WITH_RC4_128_MD5" is the most preferable cipher suite in JDK
> 1.4.2, but in JDK 7, "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384" becomes
> the most preferable one.
> So unless you use the default cipher suites, it is not good to trust the
> order of supported cipher suites.
> Hope it answers your questions.
> Regards,
> Xuelei

Thanks for addressing my questions Xuelei, it is a shame regarding the
specification but yes I understand that it is best to stay with the status quo
given it isn't new specification and backwards compatability is a concern. It is
also better to follow previous behaviour, even when that behaviour hasn't been
documented and cannot be relied upon.

Best regards

More information about the security-dev mailing list