Created attachment 821065
Specify only the three supported curves
The attached patch should resolve the issue.
Looking at the code, I don't think NSS is being used for its TLS 1.2 implementation at all:
"* TLS 1.2 uses a different hash algorithm than 1.0/1.1 for the PRF calculations. As of 2010, there is no PKCS11-level support for TLS 1.2 PRF calculations, and no known OS's have an internal variant we could use. Therefore for TLS 1.2, we are updating JSSE to request different provider algorithms (e.g. "SunTls12Prf"), and currently only SunJCE has these TLS 1.2 algorithms. If we reused the names such as "SunTlsPrf", the PKCS11 providers would need be updated to fail correctly when presented with the wrong version number (via Provider.Service.supportsParameters()), and we would also need to add the appropriate supportsParamters() checks into KeyGenerators (not currently there).In the future, if PKCS11 support is added, we will restructure this."
which is where the mismatch occurs. Instead of probing providers for which curves they support, the OpenJDK TLS code hardcodes a set list and uses that in its implementation of the Hello ECC curves extension.
The fix just cuts that list down to the three NSS curves. I don't know why this wasn't designed so as to use an API to ask providers for the curves they support. We obviously can't add it to 7 now.
Created attachment 821065
Specify only the three supported curves
The attached patch should resolve the issue.
Looking at the code, I don't think NSS is being used for its TLS 1.2 implementation at all:
"* TLS 1.2 uses a different hash algorithm than 1.0/1.1 for the PRF calculations. As of 2010, there is no PKCS11-level support for TLS 1.2 PRF calculations, and no known OS's have an internal variant we could use. Therefore for TLS 1.2, we are updating JSSE to request different provider algorithms (e.g. "SunTls12Prf"), and currently only SunJCE has these TLS 1.2 algorithms. If we reused the names such as "SunTlsPrf", the PKCS11 providers would need be updated to fail correctly when presented with the wrong version number (via Provider. Service. supportsParamet ers()), and we would also need to add the appropriate supportsParamters() checks into KeyGenerators (not currently there).In the future, if PKCS11 support is added, we will restructure this."
which is where the mismatch occurs. Instead of probing providers for which curves they support, the OpenJDK TLS code hardcodes a set list and uses that in its implementation of the Hello ECC curves extension.
The fix just cuts that list down to the three NSS curves. I don't know why this wasn't designed so as to use an API to ask providers for the curves they support. We obviously can't add it to 7 now.