Broker spoofing - How hard should we work to discourage or prevent it?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Broker spoofing - How hard should we work to discourage or prevent it?

grampajohn
Administrator
In the current design, all brokers send messages to a single queue in the server, and the server uses the broker username in incoming messages to associate them with individual brokers. Individual brokers listen on queues whose names are derived from their usernames. Brokers are given the usernames of the other brokers at the beginning of the game. Therefore, it would be trivial for broker A to send a message to the server using broker B's username, or for broker A to send a message to broker B pretending to be the server. Although I don't expect any competitors would actually do this, there would be no way to detect it, and the results of the competition will be more credible if we put some effort into discouraging it.

I have been thinking of ways to deal with spoofing that will be minimally disruptive to broker developers and to performance. The standard way to secure Active MQ is with JAAS, based on public-key crypto. Do we need this? It would be enough to sign messages; they would not need to be encrypted. A simpler way would be to exchange some information between server and broker when the broker logs in, keeping in mind that the login happens before any game-specific messages are sent in either direction. For example, the name of the broker's queue could be determined by the broker and included in the login message (BrokerAuthentication). It could be a random number, for example. In the other direction, the server could provide a "key" to the broker in the BrokerAccept message that is then prefixed to each message sent by the broker to the server.

I am confident that we could implement the second method quickly; it would involve adding a field to the two login message types, generating a queue name for login, and receiving the key and prepending it to outgoing messages. All the changes would be in the broker core. On the other hand, I have no experience using JAAS or configuring Active MQ or Spring to use it, and I don't know what the performance impact would be. If we are to follow this path, I would need someone else to take responsibility; I don't have time right now to dig into this stuff.

I invite your input and ideas over the next few days. There may be a simpler approach that I have not thought of. Also, keep in mind that in a tournament situation there is a third party that could participate - the Tournament Manager, where brokers must log in to get the server URL, and that the server can communicate with the Tournament Manager. This could be used for key distribution, for example.

I would like to have a tested solution in the upcoming 0.5.0 release, and I would like to have that release out in the next two weeks.

Thanks much -

John
Reply | Threaded
Open this post in threaded view
|

Re: Broker spoofing - How hard should we work to discourage or prevent it?

markus
In my eyes, the fundamental trade-off here is the one between the level of security, and the performance overhead incurred. I would estimate that the additional programming/configuration are about the same for the two proposed approaches.

Personally, I favor the second approach, i.e. shared secrets in queue names or message headers.

The security requirements for the competition are not immense, as you point out in your original post. The purpose of the mechanism should mainly be to avoid erroneous posts, and to discourage attacks come free of cost. I'm worried more about the performance overhead that signing every message would entail, in addition to the already costly XML marshalling procedure.

Cheers,

Markus




Am 02.04.12 17:28, schrieb grampajohn [via Power TAC Developers]:
In the current design, all brokers send messages to a single queue in the server, and the server uses the broker username in incoming messages to associate them with individual brokers. Individual brokers listen on queues whose names are derived from their usernames. Brokers are given the usernames of the other brokers at the beginning of the game. Therefore, it would be trivial for broker A to send a message to the server using broker B's username, or for broker A to send a message to broker B pretending to be the server. Although I don't expect any competitors would actually do this, there would be no way to detect it, and the results of the competition will be more credible if we put some effort into discouraging it.

I have been thinking of ways to deal with spoofing that will be minimally disruptive to broker developers and to performance. The standard way to secure Active MQ is with JAAS, based on public-key crypto. Do we need this? It would be enough to sign messages; they would not need to be encrypted. A simpler way would be to exchange some information between server and broker when the broker logs in, keeping in mind that the login happens before any game-specific messages are sent in either direction. For example, the name of the broker's queue could be determined by the broker and included in the login message (BrokerAuthentication). It could be a random number, for example. In the other direction, the server could provide a "key" to the broker in the BrokerAccept message that is then prefixed to each message sent by the broker to the server.

I am confident that we could implement the second method quickly; it would involve adding a field to the two login message types, generating a queue name for login, and receiving the key and prepending it to outgoing messages. All the changes would be in the broker core. On the other hand, I have no experience using JAAS or configuring Active MQ or Spring to use it, and I don't know what the performance impact would be. If we are to follow this path, I would need someone else to take responsibility; I don't have time right now to dig into this stuff.

I invite your input and ideas over the next few days. There may be a simpler approach that I have not thought of. Also, keep in mind that in a tournament situation there is a third party that could participate - the Tournament Manager, where brokers must log in to get the server URL, and that the server can communicate with the Tournament Manager. This could be used for key distribution, for example.

I would like to have a tested solution in the upcoming 0.5.0 release, and I would like to have that release out in the next two weeks.

Thanks much -

John



To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Broker spoofing - How hard should we work to discourage or prevent it?

grampajohn
Administrator
I have implemented, tested, and pushed an update that implements the two-secret method. The broker's secret is the name of its queue, which is sent to the server at login time. The server's secret is a key, sent to the broker in the login response. The server sends messages to the broker's queue, and the broker prepends the key to each outgoing message after the login interaction. The server compares the key on each message to the saved key for the corresponding broker (this works because every incoming message contains a "broker" field) and then strips it off before running it through the processing chain.

Affected modules include sample-broker (core modules only), common, server-interface, default-broker, and server-main. Once you update the server, you will need an updated broker, and vice-versa. I have also re-deployed common and server-interface to the snapshot repo (0.5.0-SNAPSHOT).

Please let me know if you have trouble with this.

John
Reply | Threaded
Open this post in threaded view
|

Re: Broker spoofing - How hard should we work to discourage or prevent it?

grampajohn
Administrator
One side-effect of the anti-spoofing implementation is that the broker can now be started before the server is running. It will keep looking for the server until it sees it, then create its queue and attempt to log in. This should make it much more convenient to set up ad-hoc games.

Cheers -

John