-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decrypting a compressed JWT from ruby-jwe fails #37
Comments
One caveat is that even when using |
So I made it work, but interestingly, I had to create an intermediate string to feed into
|
Hi @hagmonk After refreshing a little bit the memory, I think that the buddy impl is correct. The JWE RFC specifies that deflate (RFC1951) should be used. The JDK Looking at the ruby impl, it seems that it uses the zlib library as is, that by default generates zlib stream of bytes (RFC1950), that is incorrect in terms of JWE specification. So I think that it should be fixed in ruby impl. It can be fixed just passing the correct |
Cool, thanks for the research here. I will file an issue with those guys. What are your thoughts on applying Postel's law in this case? Adhere strictly to JWE RFC for data you generate, but tolerate some non-comformant incoming data as long as the intent is clear? |
|
Thank you @niwinz ! |
I was attempting to decode a JWT from ruby-jwe that had been zipped.
This library falls through to Zlib::Deflate to handle compression. This creates a problem for buddy.util.deflate/uncompress, which gets an exception:
CompilerException java.util.zip.ZipException: invalid stored block lengths
The root cause is creating the Inflater with nowrap set to true. Setting this value to false results in correct decompression. But I spent more time looking at this than I should have :)
Reading the docs it's kind of confusing because it states:
This makes it sound like they're harmless to have left in there, but it clearly fails if set to true.
Then it goes on to say
You're using the nowrap option but you're not passing in any dummy bytes (that I saw). Yet this apparently doesn't break unwrapped input.
I spent some time fiddling but can't afford to go too far down the bit twiddling rabbit hole. So instead I have a "just try it again" patch that you might be ok with, or you might want to root cause further. Of course if there's anything I can do to help just let me know. Pull request incoming.
The text was updated successfully, but these errors were encountered: