Should Sockets be secured

Question

I am working on an update function for a pet project of mine, and was wondering if I need to spend the time to make sure my connections are secure?

Basically the client sends the version number of the software on the users computer to a server, the server checks the users version against the latest version available, and if a newer version is available the server sends a url where the update can be downloaded from.

With this simple communication is it necessary to worry about SSL or other security measures?

I am writing the update server and client in C#, and this is the first time I've worked with Sockets in C#.

Answer 1

Short answer: I would definitely use SSL here -- you want to be certain that The Answer ("yep, new version - and here it is") came from YOU, not a man-in-the-middle attacker.

Oh, and one other point: in terms of "taking the time to do this," SSL is basically free to the developer: though you'll have to pay-for and install an SSL cert on your server the client-side work is basically zero (e.g., use https://, rather than http://).

EDIT: Though mentioned in the comments, there's no need to spent lots of cash for a SSL certificate. GoDaddy, for example, sells SSL certs for between $9 and $12 (depending on today's offer). Despite what the Verisign rep might like you to think, there's just no good reason for spending hundreds of bucks for a "brand name" SSL cert: modern browsers have a robust root CA list which includes these cheap SSL cert guys.

Answer 2

If you don't use SSL, an attacker could poison the client computer's DNS records with a fake record to your server, actually pointing to the attacker's fake server.

When the client that is curious about need for upgrade attempts to contact www.yourdomain.com, the operating system will make a DNS request to find the IP address associated with that name. The client DNS request will be sent to whatever DNS server is configured on that client. For example, the client DNS server might be their wireless router, which in turn is configured to contact the ISP DNS server. The ISP's server contacts the root authority, which refers the request to your "authoritative" DNS server. At this point in the normal (unhacked) scenario, the DNS server contacted first by the client receives, and caches, the response. This response is in turn sent to the client, satisfying the request for a name to IP address mapping.

The purpose of contacting a nearby DNS server is to allow that server to cache the response, so that subsequent lookups for the same name return quickly and without generating off-network traffic. This cache can be a weakness. If an attacker "poisons" the DNS cache that is going to be queried, they can effectively "hijack" your name to IP address mapping, from the perspective of the client that is using that cache.

The fake server could then inform a client to 'upgrade' to trojan horse software.

So the answer "depends on your liability." Whatever answer holds for the negotiation you describe should also be applied to download the client -- otherwise attacker can potentially be in the middle of that download and change what is downloaded.

I would suggest you do use SSL, but the answer depends on business factors more than technicalities of your version negotiation.

The above answer leaves aside the fact that recently SSL was found vulnerable to man-in-the-middle attacks. This will be fixed by various SSL implementations soon enough that I really only mention it in passing. It's nothing to worry about, and the point is that SSL is designed precisely to prevent the sort of attack I described.

Answer 3

Depends on your purpose. If you need a connection that is difficult for a third party to intercept, yes go with encryption/SSL. If you are sending information where network resources or processing resources are costly, you may want to reconsider the decision to use a secure channel. If you are sending information to/from mobile devices, the [good to best] encryption/decryption techniques are very costly and will slow down your application's ability to communicate. Also, if you are trying to send information that is quite bursty or intensive (i.e. video or audio+video streams) encryption with reduce your transfer speed to a fraction of what you could without it.