Thank you that helps me greatly for when I get to making the networking part of my game.

Bad guys can make malformed packets and hacked data and log their own traffic, passing it through the armored delivery services too. Bad guys can set up their own botnet of cheaters and connect securely. Bad guys can install their own aimbots and connect securely. Bad guys can introduce exploitable network messages and still connect securely.

A bit confused on what you mean by this. Do you mean that despite me setting up my server program (when i get there that is) to have only certain things as acceptable messages for controlling the game from the client side that they can cheat / create their own rules???

Do you mean that despite me setting up my server program (when i get there that is) to have only certain things as acceptable messages for controlling the game from the client side that they can cheat / create their own rules???

Yes, they can still cheat.

Encryption only protects data in transit.

Example: Encryption protects the data between the customer and the bank. Encryption also protects the data between the bad guy and the bank. Encryption does not prevent a bad guy from opening a web browser in a debugger, opening a secure connection, and telling the bank to transmit millions of dollars from one account to another. Encryption only protects from evesdroppers.

Another example: Encryption protects data from the sender and receiver. Encryption does not prevent either side from doing anything with the data once it is there. The sender can potentially send invalid data, wrong addresses, stolen credit card numbers, or any other bad data, the other side still needs to validate it.

Another example: Encryption means that once the game sends the data off to you the data is more secure in transit. However, the player on their own computer can perform a very simple man-in-the-middle attack. (Many corporate networks install a man-in-the-middle certificate for HTTPS as a standard policy, it is quite easy.) The game can transmit data to the intermediate machine, the intermediate machine can make a minor adjustment to the data such as modifying a score, and then encrypt it and send it off to the server.

Another example: Encryption between end points does not protect your executable. A player could attach debugging tools or scripts to your program. Perhaps there is a rare powerful card in the deck. If the client is in charge of their own deck an attacker could modify the shuffle to guarantee the card is present every time. If your protocol lets the client tell what cards are in the hand, the player could play the powerful card every single turn twenty turns in a row even if you intended for there only to be one of those cards. Encryption does not protect against any invalid data.

Another example: Several online attackers have found secret debug commands in the protocols for things like an instant-kill, or commands for moderators to kick or ban players. They modify the program to transmit the commands over the secure connection. Encryption will not protect from these commands.

In all cases your server must control the data from beginning to end. Your cards must be shuffled on the server and you tell the player what cards are in their hand. When the player says they take an action with a card you need to verify that they really have the card in their hand and that the action is valid at that time. If the player says to transfer something from one account to another you need to verify that the items are present in both and the player has permission to do the transfer, as well as validating that the transfer meets any rules on transfers. If you have an event like a moderator kicking/banning a player you need to verify that the sender has permissions to actually perform the actions. Even if your communication is encrypted you need to validate that every command and event is valid, that the target of the command or event is valid, that the account is authorized to do the command or action, and otherwise validate every aspect of the content.

In all cases your server must control the data from beginning to end. Your cards must be shuffled on the server and you tell the player what cards are in their hand. When the player says they take an action with a card you need to verify that they really have the card in their hand and that the action is valid at that time. If the player says to transfer something from one account to another you need to verify that the items are present in both and the player has permission to do the transfer, as well as validating that the transfer meets any rules on transfers. If you have an event like a moderator kicking/banning a player you need to verify that the sender has permissions to actually perform the actions. Even if your communication is encrypted you need to validate that every command and event is valid, that the target of the command or event is valid, that the account is authorized to do the command or action, and otherwise validate every aspect of the content.

OK. I had posted earlier that I was going to only have the client responsible for drawing the information that is necessary for interacting with the game, as well as sending what the client wants to do to the server. The server was going to interpret what the user wants to do based on what state the game has that player on the server (basically checks to make sure that if they are in a game that they can't trade with a player for example or edit their deck, etc). If this was what you were meaning, I was already planning on making sure that the player can't do something that they aren't supposed to be able to do unless the server says its fine.