how to disable pattern based subscription (security concerns)

#1

Hi,

I just read about the wildcard subscription and I’m not sure I fully understand its security impact.
I’m still rather illiterate with crossbar und just use it for some simple applications, where it works perfectly.

I wanted to implement an authentification less application with private pub/subs

The idea was,
that I used the topic name containing random characters. for example.

chat.channel.0634534534
and that the channel number is the shared secret between the publisher and subscriber(s) (e.g. chat room)

This would mean, nobody else can subscribe (listen to the channel) exchept they guesed the channel id.

The small problem, that I have now is the pattern based subscription.

somebody wanting to listen to all chats could just subscripe to the prefix
“chat.channel.” with the option. { match: “prefix” }

Is there any way to configure crossbar.io such, that I could block this wildcard subscription,
either for the entire crossbar or at least for certain prefixes?

Somehow I don’t like the idea, that somebody could just sniff on all channels with a wildcard subscription.

Is that possible or would the recommended way be to
register a specific secret RPC call for the reception of private messages?

thanks in advance for comments / suggestions ideas.

0 Likes

#2

Hi Gelonida!

First of all: Great to see that you’ve stuck with Crossbar and are using it!

There’s no way to prevent prefix subscriptions either in principle or for certain prefixes.

Using RPCs would be a workaround, but it’s a somewhat strange use of the pattern.

When using dynamic authorization, you can also authorized based on the sessionID, so for client-to-client communication this would work without using authentication.

Just out of curiosity: How are you exchanging the secret between the clients?

Regards,

Alex

···

Am Freitag, 21. August 2015 10:36:34 UTC+2 schrieb Gelonida Gel:

Hi,

I just read about the wildcard subscription and I’m not sure I fully understand its security impact.
I’m still rather illiterate with crossbar und just use it for some simple applications, where it works perfectly.

I wanted to implement an authentification less application with private pub/subs

The idea was,
that I used the topic name containing random characters. for example.

chat.channel.0634534534
and that the channel number is the shared secret between the publisher and subscriber(s) (e.g. chat room)

This would mean, nobody else can subscribe (listen to the channel) exchept they guesed the channel id.

The small problem, that I have now is the pattern based subscription.

somebody wanting to listen to all chats could just subscripe to the prefix
“chat.channel.” with the option. { match: “prefix” }

Is there any way to configure crossbar.io such, that I could block this wildcard subscription,
either for the entire crossbar or at least for certain prefixes?

Somehow I don’t like the idea, that somebody could just sniff on all channels with a wildcard subscription.

Is that possible or would the recommended way be to
register a specific secret RPC call for the reception of private messages?

thanks in advance for comments / suggestions ideas.

0 Likes

#3

Hi Alexander,

There’s no way to prevent prefix subscriptions either in principle or for certain prefixes.

Using RPCs would be a workaround, but it’s a somewhat strange use of the pattern.

When using dynamic authorization, you can also authorized based on the sessionID, so for client-to-client communication this would work without using authentication.

You mean, that I had to add some code to my crossbar, that would allow subscription to chat.incoming.sessionID and reject all requests, where the sessionID does not correspond.
Well this will be the first time I’ll modify code running on the crossbar itself. Will give it a shot.
Have to read the spec. I assume I can block subscribes only but allow publish?

Just out of curiosity: How are you exchanging the secret between the clients?

Ouch the question that hurts :wink:

Initially (in order to avoid further thinking) I thought about out of band communication (SMS / phone / PGP-mail ) which is good enough for some use cases.

One use case would be a set of dedicated apps (running on a few machines by power users having access to the secret key) which should be allowed receiving confidential information from many clients.
thus everybody should be allowed to publish, but just some privileged users should be allowed to receive.

Another use case (in the later future) would be something like the creation of private chat rooms with no centralized intelligence or master application and no encryption apart from the https protocol to communicate wit a rather stupid crossbar.

I wanted to be able, that such a chat client could use an out of the box crossbar without any modification (just tell anybody to pip install and run a default Xbar, publish its address and let all participants connect being able to create private groups amongst them). Imagine people playing a board game and wanting to have private conversations (2 or more persons per chat) via a preloaded mobile phone’s app (just having to enter the IP of a plain simple crossbar)

I imagined it like this. (idea is as I said to have no centralized intelligence)

  • Everybody can see the list of participants in a certain world (use for example the channel “players_of_game.game1” )

  • Whenever a player joins, he notifies every other subscribed player about his presence ("hello I’m there and my name / id is)

  • Everbody who’s still alive will reply with “I am here”. I think there’s more optimal solutions to know who’s alife and subscribe to a channel but this would do.
    At this point all participants know about each others presence.

  • Now any player can register an RPC call with a predefined naming style. So now each player has a way to send a secret message to any other player.

  • Whenever one wants to enter into a private communication with somebody one could send a chat request via RPC and receive a random invisible pub/sub channel id to communicate with.

If hidden channels existed the problem would now be solved without any specialized central crossbar.
Now I could establish secure point to point chats and I could create group channels and share them via the point to point chats with all participants which could participate at a specific
topic.

Am I the only one who would benefit from non observable ‘wildcardable’ channels?

An alternative approach would of course be to create a special crossbar configuration and deliver it as part of the default repository allowing such chats.
However I really liked the idea, that crossbar itself doesn’t have to do any book keeping of chat rooms and participants except the default register / pub / sub / call methods.

···

On Friday, August 21, 2015 at 1:36:49 PM UTC+2, Alexander Gödde wrote:

0 Likes

#4

Hi Gelonida!

Dynamic authorization is a feature of Crossbar as it is - it does not require any modifications to Crossbar itself. The authorization is handled by a WAMP component which is called by Crossbar and returns whether the action is allowed or not.

Otherwise: I see your use case. Looking at the current way Crossbar is configured I do not see any obvious way in which URIs exempt from prefix subscription could be excluded.

Regards,

Alex

···

Am Freitag, 21. August 2015 19:40:36 UTC+2 schrieb Gelonida Gel:

Hi Alexander,

On Friday, August 21, 2015 at 1:36:49 PM UTC+2, Alexander Gödde wrote:

There’s no way to prevent prefix subscriptions either in principle or for certain prefixes.

Using RPCs would be a workaround, but it’s a somewhat strange use of the pattern.

When using dynamic authorization, you can also authorized based on the sessionID, so for client-to-client communication this would work without using authentication.

You mean, that I had to add some code to my crossbar, that would allow subscription to chat.incoming.sessionID and reject all requests, where the sessionID does not correspond.
Well this will be the first time I’ll modify code running on the crossbar itself. Will give it a shot.
Have to read the spec. I assume I can block subscribes only but allow publish?

Just out of curiosity: How are you exchanging the secret between the clients?

Ouch the question that hurts :wink:

Initially (in order to avoid further thinking) I thought about out of band communication (SMS / phone / PGP-mail ) which is good enough for some use cases.

One use case would be a set of dedicated apps (running on a few machines by power users having access to the secret key) which should be allowed receiving confidential information from many clients.
thus everybody should be allowed to publish, but just some privileged users should be allowed to receive.

Another use case (in the later future) would be something like the creation of private chat rooms with no centralized intelligence or master application and no encryption apart from the https protocol to communicate wit a rather stupid crossbar.

I wanted to be able, that such a chat client could use an out of the box crossbar without any modification (just tell anybody to pip install and run a default Xbar, publish its address and let all participants connect being able to create private groups amongst them). Imagine people playing a board game and wanting to have private conversations (2 or more persons per chat) via a preloaded mobile phone’s app (just having to enter the IP of a plain simple crossbar)

I imagined it like this. (idea is as I said to have no centralized intelligence)

  • Everybody can see the list of participants in a certain world (use for example the channel “players_of_game.game1” )

  • Whenever a player joins, he notifies every other subscribed player about his presence ("hello I’m there and my name / id is)

  • Everbody who’s still alive will reply with “I am here”. I think there’s more optimal solutions to know who’s alife and subscribe to a channel but this would do.
    At this point all participants know about each others presence.

  • Now any player can register an RPC call with a predefined naming style. So now each player has a way to send a secret message to any other player.

  • Whenever one wants to enter into a private communication with somebody one could send a chat request via RPC and receive a random invisible pub/sub channel id to communicate with.

If hidden channels existed the problem would now be solved without any specialized central crossbar.
Now I could establish secure point to point chats and I could create group channels and share them via the point to point chats with all participants which could participate at a specific
topic.

Am I the only one who would benefit from non observable ‘wildcardable’ channels?

An alternative approach would of course be to create a special crossbar configuration and deliver it as part of the default repository allowing such chats.
However I really liked the idea, that crossbar itself doesn’t have to do any book keeping of chat rooms and participants except the default register / pub / sub / call methods.

0 Likes

#5

Hi Gelonida,

so you want everyone who happens to know or guess the number 0634534534 to be allowed to subscribe to chat.channel.0634534534, but disallow everyone from doing a prefix-based subscribe on chat.channel.?

If so, then as Alex mentioned, this isn’t possible using static authorization.

Because we knew we couldn’t foresee every possible authorization rule nor force everything into a rigid static scheme, there is http://crossbar.io/docs/Authorization/#dynamic-authorization

Here is how that would look like https://github.com/crossbario/crossbar/issues/430

Cheers,
/Tobias

···

Am Freitag, 21. August 2015 10:36:34 UTC+2 schrieb Gelonida Gel:

Hi,

I just read about the wildcard subscription and I’m not sure I fully understand its security impact.
I’m still rather illiterate with crossbar und just use it for some simple applications, where it works perfectly.

I wanted to implement an authentification less application with private pub/subs

The idea was,
that I used the topic name containing random characters. for example.

chat.channel.0634534534
and that the channel number is the shared secret between the publisher and subscriber(s) (e.g. chat room)

This would mean, nobody else can subscribe (listen to the channel) exchept they guesed the channel id.

The small problem, that I have now is the pattern based subscription.

somebody wanting to listen to all chats could just subscripe to the prefix
“chat.channel.” with the option. { match: “prefix” }

Is there any way to configure crossbar.io such, that I could block this wildcard subscription,
either for the entire crossbar or at least for certain prefixes?

Somehow I don’t like the idea, that somebody could just sniff on all channels with a wildcard subscription.

Is that possible or would the recommended way be to
register a specific secret RPC call for the reception of private messages?

thanks in advance for comments / suggestions ideas.

0 Likes