to continue my question.... are there any technical information about their data connection that how thir whole network works? game like clash of clans or....

to continue my question.... are there any technical information about their data connection that how their whole network works? game like clash of clans or....

In short never try and write your own encryption, use something tried and tested like an ssl library.

i think ssl is specially for web. maybe its possible to work with it in sockets. im not writing my on encryption. im using using System.Security.Cryptography; what can be problem of working this way? my just probable problem i think is RSA may be heavy process for encrypt and decrypting strings

Ssl works on any tcp connection. It is protocol agnostic and acts as a layer on top of the raw connection hence its name "secure socket layer"

It does add to processing time and therefore lag, so might not be a good idea. For certain your authentication and login process should be secured by ssl if nothing else.

I do repeat, do not implement it yourself. Even if you are using udp, you can make ssl work with it with a bit of forward thought.

There is no information about how things like clash of the clans work because these are closely guarded industry secrets which are not something you can just Google up. Security is layered and being tight lipped (security through obscurity) is one of many such layers.

RSA is super slow and is typically only used for handshaking and symmetric key exchange, then a symmetric algorithm such as AES is used. This is what SSL does. SSL is used by tons of things, secure web, secure FTP, SSH, current mail protocols, and so on.

If you use a TCP connection and can keep it open, the SSL overhead will probably be fine. It's mostly the handshake that's the problem. Unless you are like an MMO, but then you'll probably need reverse proxies and load balancing anyway. SSL is probably going to be the fastest encryption solution you can find. Doing it yourself will either be less secure or slower.

Check out the System.Net.Security.SslStream.

RSA is super slow and is typically only used for handshaking and symmetric key exchange, then a symmetric algorithm such as AES is used. This is what SSL does. SSL is used by tons of things, secure web, secure FTP, SSH, current mail protocols, and so on.

If you use a TCP connection and can keep it open, the SSL overhead will probably be fine. It's mostly the handshake that's the problem. Unless you are like an MMO, but then you'll probably need reverse proxies and load balancing anyway. SSL is probably going to be the fastest encryption solution you can find. Doing it yourself will either be less secure or slower.

Check out the System.Net.Security.SslStream.

thank you for answering to me. i have read the code before but need information how it works. as i saw the code, there is no code for encrypting. is the encryption process automatic? does it work like rsa? what does X509Certificate do? is this for being sure that data is from valid client and... ? ill be gratefull for more information about what you know about ssl.

There is also this "up" secured operating with server, that is layerd on IP authentification. This demands a static IP on the client, but once client authentices his end, he cannot be impersonated or faked, unless physical access to authentic IP end.

Of course this is not a solution for a game with comon players, IPs change like mad.

thank you for answering to me. i have read the code before but need information how it works. as i saw the code, there is no code for encrypting. is the encryption process automatic? does it work like rsa? what does X509Certificate do? is this for being sure that data is from valid client and... ? ill be gratefull for more information about what you know about ssl.

Yes, the actual data encryption is automatic. It uses RSA and (probably) AES internally.

SSL does two things. The most obvious thing is that it encrypts data, but it also has mechanisms to verify peers. For example, when you connect to your bank, you want to make sure not only that the communications are encrypted, but you also want to be sure that it really is your bank that you are talking to. Such verification can be performed using an asymmetric encryption algorithm (such as RSA) and a certificate chain. The whole process is a bit to complex for me to write here, but the point is that some authority who everyone trusts can issue a non-fakeable (in theory at least) certificate to someone which can then be verified by others. The certificate contains the public encryption key to be used when communicating with that entity. The most common format of these certificates is X.509.

You can create a self-signed certificate with your own keys. This is typically used for testing or when you only need encryption.

The reason for using a trusted certificate system is that it prevents man-in-the-middle attacks where a your client unknowingly connects to a hacker who decrypts the data, reads it, re-encrypts it and passes it on to you. That can also happen with a self-signed certificate unless it's shipped with the client.

Correctly doing encryption is hard. You should probably read up on it on wikipedia or similar.

EDIT:

Certificates are most commonly used to verify servers, but they can also be used to verify clients. That could be used for white-listing for example. I'm not sure I've ever seen anything that actually uses client certificates however.

Ive looked at MMORPG griefing issues for a long time and have seen games largely ruined for newbie players by a game company doing nothing effective (for years) to stop abuse (which really often only requiring very simple fixes).

There is the human factor required to be part of the countermeasures.

A problem is the companies dont want to spend money on staff salaries (and non-paid GMs have their own legal and abuse problems). Automatic systems can only go so far in countering a subset of possible griefing vectors, but the miscreant soon enough learn to find a way around them or something new.

SO one important thing is to have proper tools that gather the evidence (recorders) which the victims themselves can activate so that (quickly reviewable/effective) proof will be available to the few paid employees the company will permit.

Consider that the griefers will attempt to employ the very same abuse tools to further their activities (false accusations, etc..) so the tools will need the same kind of server based isolation/hack-proofing to minimize manipulations and proper tracking.

Tracking takes up server resources (recording game flow/player activities in the victims proximity), so to try to break the countermeasures the griefers may invoke/overload them constantly to try to get the company to eliminate them. But with proper tracking (and tools and a few actual humans) patterns of such behavior would be easy to spot and the users making improper use of the reporting tools can be canned immediately (requiring measures like preventing instant/quick remake of accounts to forestall the obvious there).

How far will this get you in countering the griefing? If it takes a large chunk of the perps out of their easy abuse then it will be worth it -- particularly to the companies who lose many paying customers over this issue.

Certificates are most commonly used to verify servers, but they can also be used to verify clients. That could be used for white-listing for example. I'm not sure I've ever seen anything that actually uses client certificates however.

The SSL certificate issuer i use has a website which authenticates via client certificates.

When you sign up you are issued a client certificate which is installed to your browser, you can also then use this as a valid email S/MIME certificate. Every year or two years depending on your membership you have to renew the certificate.

This certificate grants the access to the control panel where you can request new certificates for servers.

Also i have used client certificates for authentication in game clients and in business software as there isn't really anything stronger right now that can be made user-friendly, and it is much better than remotely storing passwords.

Essentially, your game server would issue the SSL client certificate to your game client which stores it and encrypts it locally with a password and that user's username.

Whenever you log in, the local game client decrypts that certificate and uses it for SSL client certificate verification, the server can reject an invalid certificate. If you change your password, this happens locally and the server never needs to know or exchange any user password, ever. There are some technical complications about how you support multiple devices, mobile devices, etc, and what you do if someones computer is reinstalled... But if you're interested in this, i'll leave these as a technical excercise to the reader... :)

Have fun!

Encryption of network traffic has really only one purpose -- to prevent a third party from seeing the contents of the message traffic.

That's it.

It doesn't even prevent a third party from tampering with the data (that would be message authentication), it just is supposed to prevent them from reading it.

Someone cheating is not a third party, they are a hostile endpoint, and that's another problem completely.