Closed Kortanul closed 6 years ago
looks like this may be a regression caused by a change in Java 8 update 121: https://bugs.openjdk.java.net/browse/JDK-8174719
@Kortanul I don't think this caused by JDK-8174719.
As far as I can tell wrensec-commons does all its own DER encoding (see DerUtils
class). Whether this is a good idea is another discussion (we might think about off-loading all this kind of low-level stuff to a good library like BouncyCastle).
Also JDK-8174719 seems to be caused by information getting lost during Base64 encoding of the signature. However in our case the signature always stays "binary" (it's never encoded / decoded).
Summary of findings discussed on Gitter:
The culprit here is that the implemented DER encoding is not correctly producing shortest form (i.e. do not have leading or trailing zeros). This was not an issue until JDK added strict signature validation.
There are 3 issues in the code:
ECDSASigningHandler#derEncode
is returning full array buffer with trailing zeros by calling ByteBuffer#array
.DerUtils#writeLength
is using two's-complement logic from BigInteger
which introduces leading zeros for values bigger than 127.DerUtils#writeInteger
is not removing leading zeros in the byte array.Those issues violate several BER/DER encoding rules.
Closed by #2.
thanks to @pavelhoral and @siepkes for getting this fixed so quickly!
on both JDK
1.8.0_141-b15
, and1.8.0_131-8u131-b11-0ubuntu1.16.04.2-b11
, trying to buildjson-web-token
in 20.0.0 ofwrensec-commons
results in the following test failures:as far as I can tell, we haven't done anything that should cause this.