0

I am using an exe application which is communicating with a Raspberry Pi device with manually configured TCP ports. The application will send data from port 1234 to the Raspberry Pi which is listening on 19000. But the communication is not encrypted. Can someone suggest me how I can do the encryption between these two ports?

I surfed a bit and got the idea that I can implement SSL over TCP. If someone has a better solutions I would love to hear it.

Anders
  • 64,406
  • 24
  • 178
  • 215
zappa
  • 1
  • 1

3 Answers3

6

I surfed a bit and got the idea that I can implement SSL over TCP

Using SSL/TLS over TCP is a good idea.

It is an established, well-known and well-studied protocol where lots of libraries can be found and lots of documentation exist. And, properly used it offers strong encryption and also protection against passive sniffing and active man-in-the-middle attacks.
But make sure you use recent TLS libraries and follow current and widely published documentation so that you actually make proper use of the security offered by TLS. Also, don't try to "cheat" by disabling certificate validation etc - while it looks like it would work it will usually be insecure.

Given that you don't have much experience in this area you should in no way try to create your own protection layer since it is very likely that you will introduce problems which you will not be aware of - see also Why shouldn't we roll our own?.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
1

You didn't mention what operating systems are involved (I presume Linux on the rPi) nor whether you have access / are comfortable with modifying the code.

While you could apply encryption in the client and server it would be a lot simpler to just implement a tunnel between the 2 devices - you point your current client at a new service on the client host and restrict the server to listening to a complementary service running on the rPi. Between the 2 new services the connection is encrypted.

There are lots of choices for the tech you use the new services, but the most practical choices are based on either TLS or ssh. For TLS you can use stunnel or stud (the same service, configured differently at each end) for ssh you use port forwarding from an ssh client such as putty/plink/ssh to the opensshd on the rPi. In both cases you should configure the firewall on the rPi to only accept connections on port 19000 from localhost.

Both methods rely on key pairs but the TLS based mechanism has a lot more choices and potential complexity. OTOH, if you are using a MSWindows client, the stunnel user interface is perhaps easier to live with than putty or plink.

symcbean
  • 18,278
  • 39
  • 73
-3

Hi Zappa and wellcome,

My suggestions is that you start with a simple algorithm such as RC4, for example, and while you are learning you can improve your solution and target as TLS as your final target. Depending on the language that you are using I will recommend you use libraries that makes the encryption easy for you, have no sense to implement AES by your self. As libraries that you can use I will recommend you start with openssl and libsodium, both are supported on the majority of the languages and will be easy for you to integrate on your program.

camp0
  • 2,172
  • 1
  • 10
  • 10
  • 1
    Isn't RC4 considered to be broken? It's been removed from newer versions of TLS. – Anders Oct 05 '18 at 09:02
  • 1
    @Anders Yea you are right RC4 is broken and will not help if you want to secure your stream -> https://blog.cryptographyengineering.com/2013/03/12/attack-of-week-rc4-is-kind-of-broken-in/ – Cyberduck Oct 05 '18 at 10:18
  • 2
    I don't think this is a good idea. Essentially it proposes to start with simple but known broken things and hopefully learn and fix fast before something gets broken: RC4 es algorithm is considered weak, no authentication against man-in-the-middle attacks was proposed and also no integrity protection against manipulation of the encrypted traffic. – Steffen Ullrich Oct 05 '18 at 10:41