Connection encryption

Post here your questions about SFS2X. Here we discuss all server-side matters. For client API questions see the dedicated forums.

Moderators: Lapo, Bax

User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Connection encryption

Postby Lapo » 11 Jun 2013, 12:33

Ok, that explains it. There's no sensible argument against political reasons :)

And I'm aware of that performance loss but for some political reasons I'll encrypt all data.

I'd suggest to use a light approach if possible, encryption can really kill the performance if you want to use the SSL, bank-like, standards.
Lapo
--
gotoAndPlay()
...addicted to flash games
User avatar
scream
Posts: 15
Joined: 03 Apr 2013, 09:06

Re: Connection encryption

Postby scream » 12 Jun 2013, 10:46

I found a simple solution to my case and I'm going to share with you.

Let me remind, I wanted to encrypt response object that is sent to the client side.

To do this,

1. put all your data into an SFSObject like you do before
2. convert the SFSObject to json(or byte array)
3. apply encryption to the returned json string (or byte array)
4. put the resulting encrypted json string(or byte array) into a new SFSObject, so that all data will be put into the new SFSObject like a UTF string (or byte array).
5. pass the newly created SFSObject to the send method.
Software Engineer
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Connection encryption

Postby Lapo » 12 Jun 2013, 10:57

Thanks,
so this works only from server to client, but not the other way around?
What kind of algorithm do you use for the encryption, if it's not a secret? :)
Lapo

--

gotoAndPlay()

...addicted to flash games
User avatar
scream
Posts: 15
Joined: 03 Apr 2013, 09:06

Re: Connection encryption

Postby scream » 13 Jun 2013, 08:20

Yes it is very secret, sorry for this :)

That is right, It is server to client.

I preferred to develop my own cipher that only adds extra a few bytes to the original data, and I will use the same cipher for client side also.
I aimed to minimize the increase of package size after encryption. I guess I succeeded because it addes at most 10 bytes irregardless of the size of actual data.

If you have any cipher suggestion to use for this purpose, it is a great pleasure to listen your suggestions.
Software Engineer
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Connection encryption

Postby Lapo » 13 Jun 2013, 08:27

Sounds very good. 10 bytes will have very low impact.
Lapo

--

gotoAndPlay()

...addicted to flash games
sfs_game
Posts: 1
Joined: 30 Jul 2013, 01:27

Re: Connection encryption

Postby sfs_game » 08 Aug 2013, 02:32

What if you need to make sure to encrypt communication between client and server so it cannot be sniffed out. My case would be a poker game where we need to make sure that the cards cannot be sniffed out and decoded by players that are not supposed to see them.

Is a private message secure enough or do we need to encrypt it further?

I guess my question is how secure is a private message. Given that in a poker game there could be a decent amount of money involved the incentive can be very high to decode what cards opponents have.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Connection encryption

Postby Lapo » 08 Aug 2013, 06:32

It's not that easy to sniff TCP socket messages...
How are you going to sniff out the network of someone who's playing with you 100 miles away?
Lapo

--

gotoAndPlay()

...addicted to flash games
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Connection encryption

Postby Lapo » 16 Aug 2013, 15:40

sfs_game wrote:100 miles away is not the problem.
But someone could be close in the same lan with you and we would need to make sure that he cannot sniff out cards.

Even if we were in the same office, connected to the same switch and router you would still have a heck of hard time trying to sniff anything.
Have you ever tried?

I.e. if you knew where someone lives you could get into his lan and try to sniff out the messages. this was the cause for some security flaw in some online poker software a while back.

I am not sure if you understand the complexity of the operation you're describing.
In order to do that, both the network and the computer of the victim would have to seriously compromised, to the point that you'd be able to do practically anything with the target's machine.

In such a situation the hacker literally owns the machine and there's no amount of network encryption that can protect the victim.

Hope it's clear
Lapo

--

gotoAndPlay()

...addicted to flash games
k0tbegemot
Posts: 8
Joined: 23 Mar 2014, 04:33

Re: Connection encryption

Postby k0tbegemot » 23 Mar 2014, 12:20

@Lapo

In some cases sniffing is fairly trivial. For example, on most public (or home) WiFi networks. Also, if SFS used to implement any kind of high stake card game, the "bad guys" will get highly incentive-ized and they WILL be able to sniff.

In one of your earlier comments you mentioned that SFS protocol is "binary" and as such somewhat more resistant to eavesdropping than plain text protocols. This is called - "security via obscurity" and it NEVER works. Again, if bad guys have a good reason to reverse-engineer the protocol, they WILL reverse engineer it.

In one other of your earlier comments you mentioned that it will be hard to modify binary stream (between client and server), but in case of card games, you dont have to modify anything. You just need to be able to observe data stream

I guess what I am trying to say - it would be REALLY nice if you guys released support for SSL. Maybe (if you dont think that it will be benefit everyone) you can publish it as an optional extension to SFS?

Cheers
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Connection encryption

Postby Lapo » 23 Mar 2014, 19:18

Hi,
thanks for your comments. I understand all points and think they make perfect sense.
On the other hand it seems we are talking about borderline cases. You would need two players in the same network one of which is able to monitor the other user's network via some unexplained mechanism.

Given your argument that "if bad guys have a good reason to reverse-engineer the protocol, they WILL reverse engineer it." we could then argue that SSL will not secure the game as well. The bad guy would still be able to accomplish his misdeeds in several ways:
1) monitoring the memory of the unkowing target's machine, thus acquiring information on his game state
2) performing a man-in-the-middle attack
3) replacing the target's a client with a hacked version

While I understand the value of SSL in a minority of cases, in general terms it doesn't seem to be adding substantial benefits for the most common scenarios where 90% of the security issues come from hardening the server side code.

I guess what I am trying to say - it would be REALLY nice if you guys released support for SSL. Maybe (if you dont think that it will be benefit everyone) you can publish it as an optional extension to SFS?

Being part of the core engine it doesn't fit the "extension" type very well, but in any case it's in our todo list, just no very high in priority.
Lapo

--

gotoAndPlay()

...addicted to flash games
k0tbegemot
Posts: 8
Joined: 23 Mar 2014, 04:33

Re: Connection encryption

Postby k0tbegemot » 24 Mar 2014, 07:41

Being part of the core engine it doesn't fit the "extension" type very well, but in any case it's in our todo list, just no very high in priority.


too bad :(

what about ability to run bluebox over HTTPS? In many cases this would be very acceptable solution.
netvortex
Posts: 23
Joined: 08 Feb 2014, 11:34

Re: Connection encryption

Postby netvortex » 18 Apr 2014, 17:16

The argument of cheating does not count at all. As an expert in this particular field i can tell you that in 1 hour i sweep through your ASM code with IDA and find everything i need to produce a bunch of hooks to get a cheat going. By no means i would go through the hassle of decyphering your binary packets and try to produce sending fake packets. If you are worried about the connection safety simply encrypt the packets themself. Putting an encryption layer on top of this beautiful and fast protocol is like buying a Mercedes s-class and then build concrete walls around it.
k0tbegemot
Posts: 8
Joined: 23 Mar 2014, 04:33

Re: Connection encryption

Postby k0tbegemot » 18 Apr 2014, 17:41

Encryption has nothing to do with cheating (almost nothing). Just think about any card game, would u want to ensure that "bad guys" can not see your cards? Encrypting packets is impractical (and actually impossible). You will need to re-implement huge chunk of SSL code (the whole business of private/public keys and initial key exchange). And most certainly this implementation will be less effective that "vanilla" SSL code. So what's the point?

Also, I don't buy this argument that SSL is too much of a CPU burden on a server. Hardware cheep. Many severely multi-user system running over HTTPS without too much trouble. It is likely that on the same iron you will get slightly slower performance... so what? Some of your users would not mind pay for bigger box in exchange for having secure client server communications.
netvortex
Posts: 23
Joined: 08 Feb 2014, 11:34

Re: Connection encryption

Postby netvortex » 18 Apr 2014, 18:28

Encrypting packets is impractical (and actually impossible).


Oh come on, this is just a quick example you can google...

Code: Select all

using System.IO;
using System.Text;
using System.Security.Cryptography;

protected void Encrypt(object sender, EventArgs e) { lblEncryptedText.Text = this.Encrypt(txtOriginalText.Text.Trim());}
 
private string Encrypt(string clearText)
{
    string EncryptionKey = "MAKV2SPBNI99212";
    byte[] clearBytes = Encoding.Unicode.GetBytes(clearText);
    using (Aes encryptor = Aes.Create())
    {
        Rfc2898DeriveBytes pdb = new Rfc2898DeriveBytes(EncryptionKey, new byte[] { 0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76 });
        encryptor.Key = pdb.GetBytes(32);
        encryptor.IV = pdb.GetBytes(16);
        using (MemoryStream ms = new MemoryStream())
        {
            using (CryptoStream cs = new CryptoStream(ms, encryptor.CreateEncryptor(), CryptoStreamMode.Write))
            {
                cs.Write(clearBytes, 0, clearBytes.Length);
                cs.Close();
            }
            clearText = Convert.ToBase64String(ms.ToArray());
        }
    }
    return clearText;
}


I don't know of any programming language that doesn't come with an easy cryptographic lib... It's a HUGE difference because a single machine would be responsible for encryption/decryption, additionally each stream would be encrypted/decrypted on that instance. smartFox does an amazing job at delivering performance, better than all other solutions in the industrie right now, with the given APIs/design you can easily implement encryption at the end-points.
k0tbegemot
Posts: 8
Joined: 23 Mar 2014, 04:33

Re: Connection encryption

Postby k0tbegemot » 19 Apr 2014, 08:02

you are joking right? do u really consider hard coding fixed encryption key into flash client acceptable solution?

Return to “SFS2X Questions”

Who is online

Users browsing this forum: No registered users and 57 guests