Securing client-server communication requires choosing the right transport method, enforcing modern encryption standards, and making deliberate decisions about protocol and port selection. This content covers VPNs, TLS-secured protocols, and the practical role of non-standard ports in reducing attack surface.
Securing Client-Server Communication
Besides the application and the server itself, we're also going to want to secure the communication between the client and the server. So what does that look like?
If our users are connecting into an application, how is it that we're going to secure this communication? One way that we could do this is using a VPN connection. This could be a VPN which a lot of times — most of the time — uses IPsec. So it uses IPsec to encrypt this and tunnel that information back. Or what we could do is do it at the application level, with TLS. At the application level we use TLS to secure that communication. We just need to choose what method we're going to use to transport this data securely.
Let's say we're using that application layer. There are still protocols that are insecure and protocols that are secure. An example of this is that the old protocol HTTP was insecure; it transferred things in clear text. Same thing with FTP, SMTP and IMAP. But what happened is we took TLS and put it over the top of this. We used it with these protocols, and then we developed HTTPS, FTPS, SMTPS. These are secure versions of these protocols. So we need to make sure that we're choosing secure versions of our protocols for this communication.
Not only do we need to choose those secure protocols, but we also have to consider cryptography. That changes with time, and the old TLS versions are no longer good. We need to be using the newer TLS versions in order to make sure things maintain security, maintain some sort of level of cryptography that's not going to be cracked.
Another thing we can do is port selection. A lot of times we don't want to mess with this. For instance, if we have a web server and it's up on 443, we probably want to keep it as 443. But there are times when we want to use non-standard ports. We could do something like 20543. Then what happens is that fewer people are going to try to attack this. We call this security through obscurity, so we don't rely on this as a form of security.
But let me tell you a little story. I had an employee that came to me. He said, "I have an SSH server. It's on port 22 and it's constantly being attacked, because that's a standard port right there." He said, "If I choose something that is a non-standard port, will it improve my situation? Will fewer people try to attack it?" And I said, well, that's security through obscurity, and that's really not a form of security. Which, once again, is true to a certain point — the idea is that they can still scan for this port, they still can find it open, they still can see that it's SSH, and they can still try to break into it. But as soon as he changed it, the issue just dropped drastically, and very few people were trying to attack his server after that, because they are looking for the low-hanging fruit. They're looking for the easy target. 22 is an easier target than 20543, which you have to go through a lot more work to find. So in certain circumstances we might want to choose a different port that we host these services on.
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →