Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Improperly Padded SSL Key Errors On Seemingly Valid Keys

I'm going to throw this out there just as a possible clue.  In my case, it had nothing to do with TLS or Jetty, but maybe it's related.

I have a system which signs request messages with a private key, and then checks that signature using the public key using vanilla java.security classes.  Occasionally, I would get an inappropriate signature exception on validation on a legitimate message.  Retrying the request, which would generate a new signature because the timestamp would change, would almost always succeed.  Very occasionally I would have to retry a 3rd time.

The method was to get the Signature of a defined set of headers, the set a signature header as BigInteger(Signature.byte[]).toString().  On the other side, it would be the reverse: signature header -> BigInteger -> Signature.byte[]. 

Occasionally the length of the byte[] array would be shorter than expected because leading zeros from the String header value would be dropped.  The solution was to add the appropriate number of leading zeros to the byte array before validating the Signature.

Apologies if this is just a distraction.

- Linus


On Thu, Aug 19, 2021 at 7:25 AM Daniel Wilkins <Daniel.Wilkins@xxxxxxxxxxx> wrote:
Hi, I’ve been trying to track down a failure in using a TLS key on top of Jetty. I had weird behavior on the app above so I downloaded standalone jetty and tried it. This config seems to be minimal enough for me to see what’s happening:

--module=https
jetty.https.port=8443
jetty.secure.port=8443
jetty.keystore=etc/keystore
jetty.keystore.password=[secret value]
jetty.keystore.format=jks

Everything else is the default settings in the start.ini file. I initially tried using a truststore as well but it doesn’t get that far when it fails to load the keystore. The key itself is just a password-protected 2048 bit rsa key. I also tried converting the key to the pkcs12 format and jetty started saying that the password was wrong, but that was just an aside; I’m more than happy to get it to work with JKS.

When I try to run it on the latest jetty 9.43 I get a trail of exceptions which bottom out at this:
Caused by: javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
at com.sun.crypto.provider.CipherCore.unpad(CipherCore.java:975)
at com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1056)
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853)
at com.sun.crypto.provider.PKCS12PBECipherCore.implDoFinal(PKCS12PBECipherCore.java:405)
at com.sun.crypto.provider.PKCS12PBECipherCore$PBEWithSHA1AndDESede.engineDoFinal(PKCS12PBECipherCore.java:437)
at javax.crypto.Cipher.doFinal(Cipher.java:2168)
at sun.security.pkcs12.PKCS12KeyStore.engineGetKey(PKCS12KeyStore.java:371)
... 33 more

The error message hints at this being caused by a bad key, but I’m able to view/manipulate the key in key tool as well as Keystore Explorer. This key is also used without any problems in other services of ours which don’t use Jetty.

Does anyone have a clue what might be going on here? I know that the errors don’t appear to come from jetty itself, but I feel like it has to be involved somewhere considering how keytools, keystore explorer, and other java services seem to be able to load it.

Thanks.
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users


--
Linus Kamb
------------------------------------------
NOAA / PMEL + UW / CICOES
office: 206.526.4356
cell: 206.795.7934

Back to the top