Bug ID: JDK-8037591 Still seeing Invalid Padding length SSL errors after the fix for JDK-8014618

Type: Bug
Component: security-libs
Sub-Component: javax.net.ssl
Affected Version: 7u51

Priority: P3
Status: Closed
Resolution: Not an Issue

Submitted: 2014-03-18
Updated: 2015-11-30
Resolved: 2015-11-25

JDK 7
7-poolResolved

Submitter complains about intermittent failures in their LDAP client : 

[11/Feb/2014:14:55:50 -0800] - OPERATION  - INFO  - conn=269 op=0 EXTENDED 
RESPONSE err=0 msg="" etime=6 
[11/Feb/2014:14:55:50 -0800] - OPERATION  - INFO  - conn=269 DISCONNECT 
[11/Feb/2014:14:55:50 -0800] - DISCONNECT - INFO  - conn=269 reason="other" 
msg="Exception caught while polling client connection 
LDAPS.128.120.32.240.42266 -- javax.net.ssl.SSLHandshakeException: Invalid 
Padding length: 210

The SSL ciphersuite in use is always ECDH based.

With the Solaris bug 20840488 fix (and not 2084048 which was mentioned earlier), JDK should no longer experience regressions when handing off crypto operations to the SunPKCS11 provider (which delegates to the pkcs11 solaris driver) - Closing this as 'not an issue'
30-11-2015
This was an earlier workaround suggested by Dev engineer : === It comes down to a regression in PKCS11, but it could be hardware at fault. don't know the details of their PKCS11 library well enough. Per SSL/TLS specs, we need to trim leading zero for DH (RFC 5246: 8.1.2), but must not trim for ECDH (RFC 4492: 5.10). The Solaris CKM_TLS_MASTER_KEY_DERIVE_DH mechanism is always trimming the leading zeros which can be shown in the reproducible test case in JIRA. Until Solaris fixes this, as a workaround, please add the following to sunpkcs11-solaris.cfg: CKM_SSL3_MASTER_KEY_DERIVE CKM_TLS_MASTER_KEY_DERIVE CKM_SSL3_MASTER_KEY_DERIVE_DH CKM_TLS_MASTER_KEY_DERIVE_DH ===
25-11-2015
This has been filed against Solaris as 19219686.
20-01-2015
Mala pointed out that this test fails with the four mechanisms in place. This is not a final regression test, sorry. It was mainly to prove the problem with PKCS11 to the Solaris team, and I added the @bug/@summary which made things confusing. If you disable all of these mechanisms, SunTlsMasterSecret will be completely disabled, as she saw. So people can't use this implementation in the SunPKCS11 provider, and the problems goes away as the most preferred provider will be selected (i.e. SunJCE). You will need a different test to ensure that the SunPKCS11 provider is not selected.
11-08-2014
I don't believe it's HW, both solaris-sparc (sca00bkv)/solaris-i586 (sca00aim) both failed.
30-06-2014
Per SSL/TLS specs, need to trim leading zero for DH (RFC 5246: 8.1.2), but must not trim for ECDH (RFC 4492: 5.10). Could be an OpenSSL, or something else. Not sure why disabling PKCS11 allows it to work, unless our SunECC implementation is wrong.
10-06-2014
Looking at the debug log in 18290301, it is using the TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite. We are seeing a leading zero in the PreMaster Secret: *** ECDHClientKeyExchange ECDH Public value: { 4, 0, 19, 5, 125, 219, 0, 141, 225, 166, 169, 88, 3, 100, 128, 177, 214, 40, 81, 102, 137, 9, 178, 25, 180, 54, 1, 216, 25 SESSION KEYGEN: PreMaster Secret: 0000: 00 CE A7 E4 7D 9A E8 08 6F 3D A4 C9 9E 58 DA 21 ........o=...X.! 0010: 48 3C 54 4F 93 FC 47 01 C4 93 27 7E 30 61 8A 2E H<TO..G...'.0a.. The workaround might be to add CKM_ECDH1_DERIVE (KeyAgreement.getInstance("ECDH") to the list of disabled ciphersuites. If I am reading the code right, the fix for JDK-8014618 did not trim on the PKCS11/ECDH variant, so it's possible our ECDH in SunEC has the same issue. Consulting with the engineers of: JDK-8014618: Need to strip leading zeros in TlsPremasterSecret of DHKeyAgreement JDK-7146728: Inconsistent length for the generated secret using DH key agreement impl from SunJCE and PKCS11 to make sure we have the right solution.
07-06-2014