0

I have a tcp server at Google cloud platform. This talks to my clients under a dynamic encryption key that will change after each time they talk.

The only thing that happens between the server and the client is that:

  • client sends its data from its 'license' key
  • and the server just replies with a new license key
  • then the connection stops

What are the things I have to watch out for? Can hackers steal data from my client outside of the encryption license key?

Improve this question
0

2 Answers 2

Reset to default
1

There are no intrinsic security problems in what you write - but there are also no actual details known since you provide only a very broad description. In general everything can have design or implementation bugs. In your case you need to specifically to watch out for the following:

  • You expose a server to the internet and process input you receive.
    This processing can have obvious bugs like believing that the input is trusted and executing code from it. It can have non-obvious bugs which result in code execution or data leakage like buffer overflows or simply logging with a library which unexpectedly does more than just logging (see log4j bug).
  • You do some kind of encryption to protect the communication.
    Based on what you write you seem to run your own instead of using established things like TLS. Not using established and widely analyzed protocols for secure communication is always a red flag since many things can be done wrong here, like missing or weak authentication and integrity protection, weak encryption or the possibility of replay.
  • You might expect the server to be available in order for the client to work.
    But the server might crash, there might be denial of service attacks etc which make your server directly unavailable or which make it very costly for you to keep the server running. Depending on the actual use case this might mean that the client will not work, which is probably not what the customer expects.
Improve this answer
4
  • Yes the problem is, I just can't manage to build a TLS. i just don't understand how to use a TLS for my tcp server. everywhere I look this is only used with web applications.
    – Christoph Sanders
    Nov 19, 2022 at 10:27
  • 2
    @ChristophSanders: If you don't understand how to use TLS then you probably do your own encryption wrong - because just using TLS is much simpler then implementing such protection correctly by your own. "everywhere I look" - I have no idea how you looked. But usually searching for "tls socket" combined with the programming language you want to use turns up enough useful hits.
    – Steffen Ullrich
    Nov 19, 2022 at 11:32
  • @ChristophSanders: It is not clear what you mean by TCP server. Do you use your own implementation of TCP? I believe you don't. I suppose you implement some protocol, may be even your own, over TCP. What you actually implement is not TCP (not transport layer), but application layer. TLS layer is between TCP layer and application layer. In particular, this means, that after you established TLS connection, you don't have to change the application logic. TLS is transparent to the application logic.
    – mentallurg
    Nov 19, 2022 at 11:53
  • @ChristophSanders: To "is only used with web applications": What is the difference to your case? What you think a web application is? We call a server a web server if - simply put - it supports HTTP protocol and provides data that can be used to build HTML pages (HTML, JavaScript, CSS). From the security point of view it doesn't matter, if the server provides HTML, or video, or data from some sensors, or some random byte streams.
    – mentallurg
    Nov 19, 2022 at 12:03
0

In addition to @Steffen Ullrich, in general, even a script-kiddie will:

  • try to send data to your server. Random data, fuzzing.
  • send LOTS of data, to trigger some strange behaviour
  • Try DoS (or DDoS) attacks (large volume attacks)

What the effect of those actions are depends a lot on your server and the access it has to the rest of your network.

A second risk is that client and server get out of sync. That means that you need to distribute initial keys again. This is assuming that the new license key is encrypted with the old license key.

The third risk is the encryption that you use. If you use xor-encryption, then don't expect this to be safe in any way. On the other hand, if you use AES-256, that is a lot better.

Improve this answer
1
  • "if you use AES-256, that is a lot better." - it still does not provide any authentication of the server to protect against MITM. And unless AEAD variants are used it does not provide any integrity protection by itself. Just being "lot better" does not mean sufficient.
    – Steffen Ullrich
    Nov 19, 2022 at 21:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .