Server Help :: View topic - Securing the TCPBiller protocol

Server Help

ASSS Questions - Securing the TCPBiller protocol

Doc Flabby - Sun Jan 28, 2007 10:23 am
Post subject: Securing the TCPBiller protocol

The TCPBiller protocol is currently unencrypted - it transmits players passwords and messages in plain text. I was thinking of possible a SSL wrapper but that would require a certificate system which is a bit too complicated for my liking.

Anyone got any other ideas?

-edit to correct title as it isn't a weakness as the protocol isn't designed to be secure in that way (duh).

CypherJF - Sun Jan 28, 2007 11:24 am
Post subject:

Well you could revise this and say, it's potentially insecure (assuming you have biller/server same machine/network and no other outside traffic

). Blowfish routine would probably be one of my picks? The key could either be hard coded in a config file or generated by the server. But there again if you broadcast the key it could be susceptible to man-in-the-middle interception.

Grelminar - Sun Jan 28, 2007 8:42 pm
Post subject:

If you consider the tcp biller protocol insecure, you should also consider both the vie biller protocol and the game protocol itself insecure, because in both cases the key is transmitted over the same connection as the "encrypted" data, making the encryption essentially useless (except for the purpose of obfuscation).

Also, saying that a certificate system "is too complicated for my liking" reveals that you don't actually understand the purpose of certificates in SSL, and so disqualifies you from talking meaningfully about security.

Doc Flabby - Mon Jan 29, 2007 6:10 am
Post subject:

Grelminar wrote:

Obfuscation is enough i think. The difference between passing the data in plain text and obfuscated, is the level of technical skill required to steal a player password. plain text, you just need to look at it.

The reasons i asked this question was i am writing a TCPBiller that implements the billing protocol. I was thinking this would be a good thing to have, at least as an option. I'm not asking anyone to write this for me. Just looking for ideas of how this could be achieved.

L.C. - Mon Jan 29, 2007 7:49 am
Post subject:

Hey, look - if this biller supports SSL, then that's good!

Doc Flabby - Mon Jan 29, 2007 2:55 pm
Post subject:

L.C. wrote:

Hey, look - if this biller supports SSL, then that's good!

erm i just though out SSL as a suggestion. I personally don't really fancy using SSL.I was looking for ideas of how to secure the communication between biller and server.

Mine GO BOOM - Mon Jan 29, 2007 4:36 pm
Post subject:

Doc Flabby wrote:

I was looking for ideas of how to secure the communication between biller and server.

Setup an SSH server on the same machine as the billing server. Run any SSH client to connect to that server, and do port forwarding. Now, on subgame, connect to your local SSH client (localhost) with the port you setup for forwarding. Everything is now encrypted nicely, and can work with both Subgame and Subbill.

Grelminar - Tue Jan 30, 2007 2:37 am
Post subject:

Obfuscation adds a barrier between obtaining the data passing through the tcp stream and obtaining the passwords. But obtaining the data in the first place requires more technical skill than unobfuscating it. Someone would need either 1) access to either the game server or billing server, 2) some piece of networking hardware in between them, or 3) the ability to spoof the biller and act as a man-in-the-middle. If they can do 1, you have bigger problems to worry about. 2 is quite difficult, and completely impractical if you control the network between the server and the biller. Even if the traffic goes over the public internet, it's still very hard. 3 is probably the easiest: you could do it by dns-spoofing or arp-spoofing if you're on the same subnet as the server. Still, you have to have a bit of a clue to pull off an attack like that. And note that obfuscation is worthless against a man-in-the-middle attack.

If you're serious about security, I would recommend setting up stunnel or similar software on the server. Generate a self-signed cert, pass it out to all the game servers you expect to connect, and let them use stunnel in client mode with that as the ca cert. That doesn't provide strong authentication of the game servers to the billing server, but that would take a lot more effort and probably not add much more security than you could get with a custom firewall to only allow known server addresses to connect.

Doc Flabby - Tue Jan 30, 2007 3:26 pm
Post subject:

ok. my concern was actually just as much with the contents of chats being transmitted in plain text as passwords being stolen. Call me paranoid - i probabbly am

, but i dont want someone saying "terrorist" or something like that in chat and then getting sent of to guantanmo. The current design of the udp biling protocol at least means that it would require any party such as this to implement the subspace protocol.

However everyones suggestions are good ways to avoid this. I think i will concentrate on fully implementing the biller before worrying more about this. (this would be an extension).

Bak - Tue Jan 30, 2007 3:47 pm
Post subject:

you don't get sent to guantanmo for saying terrorist, and you just received it over a tcp connection when you downloaded this webpage! look out

Doc Flabby - Tue Jan 30, 2007 4:06 pm
Post subject:

not yet neways. but if i started talking about "tiananmen square" in china i might

I just wonder if encrpytion isnt a good idea why are chats encrypted in the original subill, if there is no real need for it. There must be some reasoning behind this original decision/

Smong - Tue Feb 06, 2007 4:34 am
Post subject:

Chats are encrypted with subill? I would imagine since subill uses the common ss core protocol, encryption comes for free and can be on or off and the biller wouldn't care since it's a separate layer.

CypherJF - Tue Feb 06, 2007 7:17 am
Post subject:

Smong wrote:

I believe that to be the case as well.