search

crossbario / autobahn-java

WebSocket & WAMP in Java for Android and Java 8
https://crossbar.io/autobahn
MIT License
1.52k stars 427 forks source link

Added the option to pass the secret to wampcra as byte array. #524

Closed bluecatpixel closed 3 years ago

bluecatpixel commented 3 years ago

The main goal is to allow secrets with different encodings and not only UTF-8. The modification doesn't break the current string secret just add also the byte array as an option.

oberstet commented 3 years ago

according to the wamp spec, in wamp-cra, the key must be a utf8 encoded string.

bluecatpixel commented 3 years ago

I'm trying to find information about it. Can you point me where I can find this?

bluecatpixel commented 3 years ago

@oberstet Hi. I'm looking for a while in the doc https://wamp-proto.org/_static/gen/wamp_latest.html and especially in the section "14.5.2.3 Challenge Response Authentication" but I don't see where it is written that it must be utf-8 encoded. Can you help me to understand in order to also take actions if required on the project I'm involved?

oberstet commented 3 years ago

the signature is computed as

signature := HMAC[SHA256]_{secret} (challenge)

https://wamp-proto.org/_static/gen/wamp_latest_ietf.html#wampcra

here, secret is a binary.

when specifying the secret from an UTF8 encoded string key both in client and router, that will work and is well defined.

https://github.com/crossbario/autobahn-python/blob/fd5530cecff0be210b148bddf1e984ed31d2863c/autobahn/wamp/auth.py#L587

when allowing other encodings, it wouldn't be obvious how to share a key between client and router

having said that:

so strictly speaking

in wamp-cra, the key must be a utf8 encoded string.

is wrong. it only specifies binary secret and signature computation, but doesn't answer the "shared key => secret" step :(

Crossbar.io / Autobahn will only allow strings and will always UTF8 encode to come up with the binary secret needed in the signature.

now, above isn't great, but practically, why would you need anything but UTF8? just use that and everything will work ...

bluecatpixel commented 3 years ago

Thanks for the great explanation. Now I understand why I didn't found the information. To respond your question "...why would you need anything but UTF8?" , because we are sharing a secret that is not utf-8 encoding and we don't see a solution for the problem as the ChallengeResponseAuth always converts the secret to something different. Other than obviously changing the all process.

oberstet commented 3 years ago

sorry for the confusion, and kinda lacking spec text, and the hassles resulting for you.

because we are sharing a secret that is not utf-8 encoding

couldn't you decode the XYZ-encoded string into a native Java string, and then let autobahn re-encode as UTF8 to do the "key => secret" step under the hood? as far as I know, there is no XYZ encoding that would have characters which cannot be UTF8 encoded (but I'm not sure ..).

it'll depend on what router you use / if you can control the secret given to the router as needed for that.

anyways, I hope you have enough infos to find an appropriate way .. it's just that I am hesitating changing autobahn behavior rgd this (we have no need whatsoever to treat anything but utf8)

bluecatpixel commented 3 years ago

Isn't possible (I can say not only java but any) because the sharing key has different encoding and it always is converted to something different if we try to convert to utf8 and reverse it. The reason is that utf8 doesn't use the complete 8bit. Also, one requirement is that the shared key is something incomprehensible for humans. We already tested the fork with success and one possibility is to use the fork with source dependency or other options. What makes us hesitate is the fact that we may miss any fixes/updates. Also, another option is to design from scratch our lib but anyway the majority defends the use of one lib constantly maintained and updated. BTW some of us are concerned with the fact that the last release was last June so almost a year ago although we see new commits. Is there any rule you have about the release schedule? Anyway thanks again.

oberstet commented 3 years ago

the sharing key has different encoding and it always is converted to something different if we try to convert to utf8 and reverse it.

I don't think this is true. what encoding(s) are you using?

Also, one requirement is that the shared key is something incomprehensible for humans.

This is bogus. At least the encoding of a string is unrelated to "comprehensible". What should that mean anyways? openssl rand -hex 32 is pretty incomprehensible to me, and obviously an ASCII string nevertheless;)

Is there any rule you have about the release schedule?

We don't have a rule for releases, we're doing calver. we want to do a new release "soon" https://github.com/crossbario/autobahn-java/issues/521

bluecatpixel commented 3 years ago

ISO_8859_1...that's why passing as byte array is ok... another option is to pass optionally the encode...maybe also not so bad idea. Anyway, this isn't your concern correct?