what would you like to see in the vegastrike multiplayer?

[chuck_starchaser]

Perhaps a system could be developed where a server is more of an organizer that "conducts" the universe where all of the clients each handle the processing in a distributed fashion. Systems that are currently inhabited by users would be processed by the clients of those users whereas the goings on of uninhabited systems would be processed by all of the clients. Perhaps a client validation scheme could be devised to prevent hackers/cheaters from "polluting" the game environment.

Yes, I was just thinking about that reading klauss's post; the main server could handle the initialisation protocols, 1024 bit RSA, distribute smaller session keys for DES or TwoFish or whatever, and discrepancy interventions. I think part of the security would be that each mini-servelett embedded in the engine could make checks of sanity about the data from other players, and if two or more machines complain to the server about the same player, eventually the server would kick that player out. Still, every player sending data to every other player, I don't think that would work: Terribly inefficient. One machine should receive data from a number of other players and then rebroadcast it to all. But it would be good if the main server chooses a machine, or a few machines, at sort of random to do this work. Perhaps the player gets a note, "sit back and crack your nuckles for 20 minutes, you're server atm".

[Guest]

There should be a TCP option, that way everything can be piped over SSH (which is a tried and true encryption system). As for encryption being re-implemented... why even try? It is very hard to make a system that is not easy to compromise, sshV2 is one of the few systems that work well.

For other things hashes are best probably. Just have a TCP option and those servers that want lock tight security can implement it.


:::Weird Idea:::
One thing I was thinking of is a "vega-server-shell" where that program is set as user shell in /etc/passwd, the person connects as vegastrike/vegastrike (user/pass) (etc) and thus that program runs and connects the 2. The client dumps it's stuff into the shell and server sends to that program which dumps data into stdout... which the client picks up.
:::Weird Idea:::

Ofcourse that part is just a weird idea for non-trusted users.

Trusted shell users can just port forward. (Something I do when playing crossfire (real time RPG)).

[Lucky B]

The complexities with such a theory lays with dealing with errors. What if a client which is running part of the world looses the connection? What if the client is using a different version? What ifs could plague such a design.
But after considering all whatifs, it could be quite a good design. Only very complex. If anyone wants to design it, feel free to help out. But I think the centralized approach, due to its enormously higher simplicity, will take precedence unless a good distributed design comes forward.

I agree with this, what ifs really kill a trully distributed gaming system, even latency itself could be a problem. You really don't want an non-trusted client doing part of your serving.

But! It could do error checking if it's spread well enough.

Say you have 15 clients, you have each client compute position and then send 3 other (random) clients the data to confirm and check.

This could also lead to problems with clock skew and lag sometimes but it'd be a bit better.

[smbarbour]

Perhaps a scheme to determine who should "host" a system would be good. Kind of like Windows Server elections (I know, a bad analogy to use ) Each machine would have a capability factor that is calculated based on certain factors. High bandwidth, faster processor, more memory would all increase the score while high detail levels and other intensive issues would decrease the score. The user with the highest score "hosts" (and a second or maybe third user replicates the data tables it holds), with an election occuring whenever a user enters or leaves the system. If the "host" user drops connection the backup will kick in to maintain the stability.

[chuck_starchaser]

There's one problem with that: Someone who wants to host for all the wrong reasons could get a fast machine, or even hack the software so it believes it's a fast machine, and then cheat with impunity.
The other issue is bandwidth and latency. When I suggested an 8-way Opteron, I did not mean a machine that someone would buy and place in the garage. I meant you go to a service provider and ask "how much you charge for a dedicated server?". You get leasing cost as part of the deal, and you know the machine is well connected.

[Lucky B]

I still don't think untrusted hosts (ie. hosts you have no control over) should have ANY crucial part of your serving duties distributed error checking should be easy and low bandwidth, not to mention easy to filter for invalid data (almost everyone would have to be cheating) and relatively secure (the client does not need to be told which data it's checking, just to check it, ie. starting position, acceleration vector, final position, ship stats required for calculations).

[smbarbour]

I think we need to separate the two issues. For the purposes of the client/server, we should assume that the hosts have already been deemed trusted clients.

On the issue of trusting clients, perhaps the main server(s) should occasionally transmit a script that a client will execute (with a variety of authentication scripts available for the server to pick from). If the client fails to return the appropriate result from the script, the user is kicked. For example, transmit a script that checks if the user's reactor recharge value matches what their installed equipment says it should be.

Lucky B: I don't think there should be ANY untrusted hosts. If the user's software doesn't validate, they're not allowed into the game.

[chuck_starchaser]

The idea is good. This is going in the right direction, I feel. However, someone who hacks the serving code to, say, have infallible aiming, could just as easily allocate the new variables on a side, without touching the existing variables; so the requests from the server could all pass, but the variables that are actually used be elsewhere.
I've agonized over these problems, and I don't have an answer yet. I thought of having checks that ask the software to compute a checksum of itself; but a hacker could put an image of the un-touched executable in memory, and route such checks to it.
I think it would have to be something along the lines of checking code AND data checksums together, but this could be hard to implement.
And it can't be a finite number of scripts; that would be piece of cake to catalogue and defeat.

But even if we could somehow magically deal with security, the other factor is latency. The bandwidth of a DSL connection may be okay, but the latency can be pretty bad for hosting; wheras if you pay an ISP for a dedicated server, you know you got a fat pipe to some major hub (AND you have control of the software running on it, unless the hackers befriend a corrupt employee at the ISP, of course; but that's much less likely to happen).

[Guest]

may i throw in a couple of pennies worth...

I love the whole "multi layer" idea thrashed around at the beginning. Shirley each layer can happily live in its own client within a single consistant inteface, a bit like running an app like Photoshop. If someone is playing full blown PvP 3D sim they can close the unrequired windows, while those doing a bit of RTS/resource Management could have on those necessary windows open. There wouldnt be a sinlge engine but a modular design that interact where required.

On Client/Server vs Distributed. People want to play in a large enough universe to interact with others, but this typically requires a large costly server. People seem to dismiss the distibuted approach on the grounds of secruity. I believe though that this is the only way to go with a open source/free system. An authentication server is used to log on to a network, and maintains periodic checks to verify the integrity of the clients. Then each client communicates the relevant information for that player to all the others (and also carries out additional security checks to cover cheating). Let the network become the cluster. A hierarchy of authentication servers could be used to seperate clients in different universe sectors/planetry systems in order to reduce the amount of network traffic generated, and would also allow for the different mods.

As a concept, start with a single planetary system then extend to a sector and so on. Economies should natrually localise anyway and players maintaining large corporations/fleet across the universe can connect to multiple sub-clusters with less detail required on ship data.

Now im not a coder, so have no idea how complex this would be, but its seems a design issue rather than a technical one.

oct

[chuck_starchaser]

It IS a design issue, but hard as all hell. There was an article in a Game Developer issue some 3 years back, about security. You would not believe the numbers of exploitable loopholes that article covered. It was a post-mortem article, about a particular game they published (commercial). Not only did they cover loopholes, but also obfuscated to hell any attempts at finding the copy protection part of the code by A) delaying its activation to some rare times during gameplay, B) disguising the code by distributing it around and using indexed addressing and offset both for data access and code calls, and C) by delaying the response of the system to cheat or illegal copy detection, so it would let you continue playing, but sometime later there'd be apparent bugs that got worse and worse. It took hackers 1 month to crack it, and they were very proud of the accomplishment (since most games get cracked within a day).

Another article in Game Developer, about cheating, also covered enormous amounts of material, and yet ended with the note of "can't be stopped, but it can be made difficult".

But then again, RSA is open source. It may be that if the oss community put their brains to it they might find a way to do it that not only is very secure, but gets more and more secure as time goes on, like Linux. Would be interesting perhaps to propose this as an open source project in itself.

[Lucky B]

I think we need to separate the two issues. For the purposes of the client/server, we should assume that the hosts have already been deemed trusted clients.

On the issue of trusting clients, perhaps the main server(s) should occasionally transmit a script that a client will execute (with a variety of authentication scripts available for the server to pick from). If the client fails to return the appropriate result from the script, the user is kicked. For example, transmit a script that checks if the user's reactor recharge value matches what their installed equipment says it should be.

Lucky B: I don't think there should be ANY untrusted hosts. If the user's software doesn't validate, they're not allowed into the game.

In any computing environment any host you do not have complete control over is not trusted (this does not mean that you cannot run a server in some sort of cluster form). Validation can be faked, it's that easy. Distributed computing does not lend itself well to gaming applications. (if you notice distributed computing projects validate results 3 or 4 times)

[Guest]

Another article in Game Developer, about cheating, also covered enormous amounts of material, and yet ended with the note of "can't be stopped, but it can be made difficult".

So think around the cheating problem. If people want to hack a file (which is public anyway) let them. assume that the files are being hacked and provide a mechanism to spot and counter the hacks. If your using a distributed system isn't there less scope for hacking since theres no central server to fool but many different clients. The central server actually creates a security headache as all clients trust it.

Thats an advantage of going distributed i think. The clients each hold the data on the craft/cargo/objects in the game and can determine if data attributes about another players object are valid or not. A system of peer review and dissemination via the authentication servers allows for legitimate upgrades/additions.

[chuck_starchaser]

The central server actually creates a security headache as all clients trust it.

Trust is always easier to implement than mistrust, and only a headache if unworthy of the trust. If we put our efforts ensuring that the sever is in a safe place, has the proper hardware, software and connection, that's much easier to program than a distributed, mistrust based system. That's a headache! But I'm not saying it can't be done; only that it's a huge undertaking, worthy of being its own oss project.

[klauss]

There should be a TCP option, that way everything can be piped over SSH (which is a tried and true encryption system). As for encryption being re-implemented... why even try? It is very hard to make a system that is not easy to compromise, sshV2 is one of the few systems that work well.

SSL/TLS uses algorithms which are much more flexible and still secure than SSH. SSL is quite like SSH, but uses the PKI to manage keys: certificates, crls, etc.

There's no security downgrade by going from SSH to SSL. And if you think about it, using a shell client to perform interprocess communication is, at least, cumbersome (like scratching your right ear with your left hand).

OpenSSL already covers most security issues. The thing is that SSL needs a TCP connection, and the library cannot be used with UDP. So, UDP packets have to be encrypted by the client/server code. It's not hard. You get the session key and algorithm from OpenSSL, and use the same methods (only applied to UDP packets, with a different packing than that of SSL).

SSL and TLS are quite the same thing. Newer versions of SSL are called TLS. I think TLS differs from SSL in the number of underlying transport protocols it supports: TLS only needs a reliable connection, while SSL was specified around TCP. But apart from that, they're the same thing.

If you take a look at the SSH specs, the handshake is exactly what's done in SSL: the server sends a challenge, enveloped to the client, the clients replies with the server's challenge plus its own challenge, enveloped to the server, the server validates its previous challenge and then replies to the client with the client's challenge plus a session key, etc... details vary, but the idea is always what I wrote. Diffie Helman is just another way of doing key exchange (although mutual authentication must be done separately). TLS only adds variety, and a consistent key management method (the PKI).

[Guest]

I've sucessfully sniffed both SSL and SSHv1, they are similar and are easy to attack.

SSHv2... that's another story. Harder to attack (I haven't been sucessfull).

While using a "shell" program for secure communication may seem clumsy ... it isn't. It is a sensible way to get data from one machine to another quickly and in real time. SSH can also provide compression .

All I am really asking is for a TCP-only option, I program (in perl) so I know (atleast in perl) it is _not_ hard to deliver one or the other, or both.

Seriously... why are you peeps against this ... you don't have to use it on your connection or your server. It gives others the chance to though. I know what this entails as a programmer my self, it dosn't take to much extra programming so the argument "it would be too hard to implement" that non-programmers may raise dosn't hold water (so please don't raise it when if you don't spin code).

vegastrike -T -s localhost -p 9000
yay I'm connected over my ssh tunnel!

[chuck_starchaser]

All I am really asking is for a TCP-only option, I program (in perl) so I know (atleast in perl) it is _not_ hard to deliver one or the other, or both.
Seriously... why are you peeps against this ... you don't have to use it on your connection or your server. It gives others the chance to though. I know what this entails as a programmer my self, it dosn't take to much extra programming so the argument "it would be too hard to implement" that non-programmers may raise dosn't hold water (so please don't raise it when if you don't spin code).

You can use TCP with something like a card game or slot machine; but for simulation and all things real-time, UDP is the way to go. It's not a matter of wanting or not wanting or being peeped, it's a matter of objective reality. Show me one real time simulation multiplayer program that uses TCP. Crossfire doesn't count, because that's a much simpler, low res 2D environment, and more importantly, it's a cooperative game, which means that each running client can model the monsters locally, and only minimal re-synchronization is needed. Vegastrike inhabits a 3D floating point space with physics, and multiplayer will be a combination cooperative and confrontational; and only a few NPC ships might be able to be simulated independently in each running client. And even this is unlikely, as the AI is pretty complex and responsive to the environment. So syncronization will be much more of an issue. VS multiplayer will stretch connection bandwidth and be seriously affected by any latency; and TCP can't possibly work, because packets are lost, from time to time, and when that happens, TCP automatically stops the flow until it gets the missing packet re-sent, causing a big traffic jam. With real time continuous space and physics, multiplayer synchronization cannot use old, re-sent packets. If a packet is lost, "too bad", "never mind", "what's new?". Get the idea?
With TCP you *cannot* specify "I don't want lost packets re-sent". TCP mandates that a lost packet be re-sent. But re-sending a packet cuts into the time new packets need to be sent, so the problem becomes an avalanche. U.D.P, repeat with me, UDP. I know you want to use your machine as server; but VSMP is probably a year away or more, you got plenty of time to get set up so you can serve UDP...

[klauss]

I've sucessfully sniffed both SSL and SSHv1, they are similar and are easy to attack.

I challenge you to show me the script that successfully sniffed a propperly configured SSL connection. By propperly configured, I mean RSA ( >= 1024 bits) key exchange and authentication, with AES-256 encryption (or any other cipher with keys longer than 128 bits).

I doubt a perl script has the processing power to achieve that. I think you're bluffing. If you're not, prove me wrong.

You could have sniffed a poorly configured SSL connection, though. It's common that, when two-way authentication is not required, clients use an ad-Hoc certificate, with 512-bit RSA keys (which are easily factored with modern algorithms and modern hardware), and very weak ciphers (RC-2, I think, is 48-bit - Ugly). But that is not a test case, that's a bragging case. For testing, you have to use 1024-bit RSA or Diffie Helman and 256-bit symmetric ciphers. Or at least greater than 128-bits.

If you did break a 1024-bit RSA cipher, you would be fool not to have submitted the procedure to RSA itself for they offer a big prize on that (a few thousand dollars). Either you're a fool, or are waiting to use it to, say, sniff at a bank's transaction (the prize from it being greater that what RSA offers, although illegal).

Anyway, I believe you don't know what you're talking about. Please, prove I'm wrong, show the code, and we'll all bow to your wisdom.

[Guest]

ettercap.sf.net

Swaps the key out for your own using Mitm attack (easy on cable lans, wifi, your home lan).
Yes I have done it, it works. They call these "side channel attacks". This is the reason you don't roll your own encryption scheme. It may be mathmatically sound but there is more to security then math.

SSHv2 mitigates the risk.

All I'm asking for is a TCP option. I don't know why you (non programmers) are trashcanning it. Maby you should just be quiet since it won't affect you? Or do you like to argue?

An _OPTION_ . The server can disallow tcp only or allow it. Please read that word I keep typing (option). It is _not_ hard to program both. You just send your data to on sub or the other. I'm a programmer, I know. You're not a programmer, you don't know.

dict option
4 definitions found

From The Collaborative International Dictionary of English v.0.44 [gcide]:

Option \Op"tion\, n. [L. optio; akin to optare to choose, wish,
optimus best, and perh. to E. apt: cf. F. option.]
1. The power of choosing; the right of choice or election; an
alternative.
[1913 Webster]

There is an option left to the United States of
America, whether they will be respectable and
prosperous, or contemptible and miserable, as a
nation. --Washington.
[1913 Webster]

2. The exercise of the power of choice; choice.
[1913 Webster]

Transplantation must proceed from the option of the
people, else it sounds like an exile. --Bacon.
[1913 Webster]

I've sucessfully sniffed both SSL and SSHv1, they are similar and are easy to attack.

I challenge you to show me the script that successfully sniffed a propperly configured SSL connection. By propperly configured, I mean RSA ( >= 1024 bits) key exchange and authentication, with AES-256 encryption (or any other cipher with keys longer than 128 bits).

I doubt a perl script has the processing power to achieve that. I think you're bluffing. If you're not, prove me wrong.

You could have sniffed a poorly configured SSL connection, though. It's common that, when two-way authentication is not required, clients use an ad-Hoc certificate, with 512-bit RSA keys (which are easily factored with modern algorithms and modern hardware), and very weak ciphers (RC-2, I think, is 48-bit - Ugly). But that is not a test case, that's a bragging case. For testing, you have to use 1024-bit RSA or Diffie Helman and 256-bit symmetric ciphers. Or at least greater than 128-bits.

If you did break a 1024-bit RSA cipher, you would be fool not to have submitted the procedure to RSA itself for they offer a big prize on that (a few thousand dollars). Either you're a fool, or are waiting to use it to, say, sniff at a bank's transaction (the prize from it being greater that what RSA offers, although illegal).

Anyway, I believe you don't know what you're talking about. Please, prove I'm wrong, show the code, and we'll all bow to your wisdom.

[chuck_starchaser]

Asking for a TCP option is like asking for having the option of playing VS without a computer. We'll put both options just for you, mikee.

[ack2000]

ignore post wrong area

[Guest]

Asking for a TCP option is like asking for having the option of playing VS without a computer. We'll put both options just for you, mikee.

Umm... no it isn't.
Asking for a tcp option is like asking for 1 extra subroutiene.

[chuck_starchaser]

Okay, but one extra subroutine that allows you to play for about an hour if you're very lucky, but that as soon as packets start to get lost, the whole multiplayer dynamics grind to a halt, and you basically have to restart the game. I'm tired of explaining to you what packet loss does to real time synchronization when using TCP. If you don't read my posts, then replying to you is a waste of time.
But you don't think I'm a programmer, so you won't read my posts.
Okay, then get some books on C++ and try your own hand at a multiplayer implementation. If I was working on the VS multiplayer implementation I'd do so the way I believe it would work, not the way you believe it would work; you understand? And I'm not working on it myself; I'm working on Sound.

[Guest]

Okay, but one extra subroutine that allows you to play for about an hour if you're very lucky, but that as soon as packets start to get lost, the whole multiplayer dynamics grind to a halt, and you basically have to restart the game. I'm tired of explaining to you what packet loss does to real time synchronization when using TCP. If you don't read my posts, then replying to you is a waste of time.
But you don't think I'm a programmer, so you won't read my posts.
Okay, then get some books on C++ and try your own hand at a multiplayer implementation. If I was working on the VS multiplayer implementation I'd do so the way I believe it would work, not the way you believe it would work; you understand? And I'm not working on it myself; I'm working on Sound.

It's an extra option, not standard.
Since we are going to have TCP log in anyway, it won't take that much more code to just stay in TCP as a non standard option.

[klauss]

Ok. Just to be thorough, I'll check tat ettercap.

But for what I've seen up until now, it uses mitm to sniff at key echange.
I imagine it is able to successfully sniff any connection that doesn't use a sound key exchange algorithm. That would fall out of my "propperly configured" category. But, since I didn't see the entire code, and I could be wrong, I'll leave it suspended as I read through everything.

By the way... why do you keep saying

...you (non programmers)...

Have you been sniffing our connections?
Do you know anything about us?

[klauss]

Here, mikee:

you can sniff SSL secured data... a fake certificate is presented to the client and the session is decrypted.

Note 'fake certificate'. That's allowed when you use the ad-hoc certificate I was talking before. If the client is configured to perform server authentication, that fake certificate will not be accepted, and the sniffing fails.

As I said, it has to be propperly configured. SSH1 had some flaws in that it was hard (or maybe impossible) to avoid the issues, but SSL is not like that.