Should Sockets be secured

views:

answers:

Should Sockets be secured

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#.

+2 A:

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.

Heath Hunnicutt 2009-11-17 20:03:36

In this case I would think the trojan would have to be on my server anyway. Currently I'm not returning the entire url, I only return part of it. For example: The file will always be at http:\\www.mydomain.com\downloads\<some app>\<version>, so I only pass back the second part of the url (<some app>\<version>) and then I assemble the string at the client. Should I still be concerned?

Tester101 2009-11-17 20:24:24

No, the trojan would not have to be on the server. Yes, you should still be concerned. I think you better read up on "man in the middle" and "DNS poisoning/DNS hijacking." The issue is that while you know that www.mydomain.com points to your server, the attacker can confuse the client machine to think it points elsewhere. This is not hard to accomplish but the details can be found elsewhere.

Heath Hunnicutt 2009-11-18 23:14:21

-1: SSL prevents the scenario you describe here: DNS cache poisoning is an attack, but it by itself is ineffective vs. SSL: the attacker would need to be able to create a valid server cert for the domain in question in order for what you're describing to happen, otherwise there's a CN mismatch which would result in the SSL handshake failing. Remember, SSL is about both authentication and encryption.

DarkSquid 2009-11-18 23:38:50

DarkSquid: That is EXACTLY WHY I am advising that he should use SSL. That's my point. Read it again. Also, catch up on the news -- SSL was broken for man-in-the-middle 3 days ago.

Heath Hunnicutt 2009-11-18 23:54:00

I can see how my writing skill disable your reading skill, so I editted the first two sentence to make it clear what I mean. The last paragraph should have made it really clear, but I suppose if you didn't understand what I meant by "Pretend SSL...". What I meant by that was, "SSL is supposed to protect you from this, let's pretend it wasn't broken yesterday."

Heath Hunnicutt 2009-11-18 23:55:28

Stow the invectives. I assume you're referring to CVE-2009-3555. In short: yawn. Despite the hand-wringing on the web, in reality it's hardly as dangerous as your "SSL is broken" statements would lead the uninformed to believe...and it (even in combination with a DNS poisoning attack) simply doesn't have the impact you're alleging it has. That said, it would seem you and I agree he should use SSL, which is nice.

DarkSquid 2009-11-19 00:14:23

"yawn" -- yeah I am sure you were thinking of it when you read my answer, that is why you had no clue what I mean. BTW, what invective? You mean the 16 downvotes you've dispensed on 1840 reputation gained over 150 days? 16 downvotes is awfully critical, DarkSquid. Are you sure you aren't out to put down good answers while you troll for more reputation?

Heath Hunnicutt 2009-11-19 00:24:08

-1 retracted, given the rewrite/clarification.

DarkSquid 2009-11-19 01:26:55

+1 A:

To answer a question with a question, do you care if someone could possibly see what's sent over the socket?

Soonil 2009-11-17 20:03:40

Not really. you would see a string like this "1.0.2.87" go to the server and one like this "<appname>\1.0.2.88" come back. I'm more concerned about situations like the one Heath Hunnicutt described.

Tester101 2009-11-17 20:28:40

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.

DarkSquid 2009-11-18 23:41:02

-1: $495 is hardly "free", and also for misunderstanding my answer, -1-ing it, then referencing it _vis_ man-in-the-middle.

Heath Hunnicutt 2009-11-18 23:59:52

HH - Where did the $495 come from? If you're thinking about VS certs, there are plenty of cheaper suppliers: I pay about $9 for my SSL certificates via GoDaddy. Also, I'm sorry if I hurt your feeling by disagreeing with you in good faith about the impact of the over-hyped SSL attack de-jour. Do you typically retaliate in this fashion, or are ya just having a bad day here? Cheers..

DarkSquid 2009-11-19 00:25:51

Do you typically misread answers, down-vote them, then post an answer which reiterates them or are ya just having a bad day here? You didn't even disagree with me over the SSL attack I mentioned. You just didn't bother to read what I wrote before you down-voted it. And that is super lame, something you should be called on. If you then want to accuse me of "invective" but can't point to an example that precedes your accusation, and further accuse me of "retaliation," I guess you are doing damage control. What is your real name, oh pseudonymous critic?

Heath Hunnicutt 2009-11-19 00:30:18

HH: I read your post. I disagreed and provided the reason (CN mismatch), as stated. You are welcome to disagree with my disagreement (I may be wrong, as has been the case lots of times previously), but I'm frankly puzzled by the "heat" of your responses. Perhaps you mistake my disagreement with what you wrote as some sort of broad personal attack (I note your personal accusations about me, and the disappearance of your "who's downvoting out of jealousy?" comment(s)), but rest assured I'm simply disagreeing with what you said. And that's OK. There's no need to get all angsty here.

DarkSquid 2009-11-19 00:48:38

The fact is, you did not disagree with what I wrote. You mischaracterized what I wrote, then disagreed with your misinterpretation. I'm as offended by your (seemingly deliberate as it continues at this point) mischaracterizations as anything else. I never misunderstood the use of certificates in auth, as you imply. You mis-read, and continue to maintain that your misreading is what I intended. That is offensive. At this point, you seem to be a spinmeister.

Heath Hunnicutt 2009-11-19 00:57:10

HH: In fact I DID disagree with what you wrote, but now that you've rewritten it we violently agree! SO won't let me upvote due to old timestamp; if you edit it to update the timestamp I'll give ya a deserved +1 (removed downvote in the meantime) Cheers!

DarkSquid 2009-11-19 01:11:40

Anybody who cares to check the edit history can verify: although yes I improved the readability of my answer, the meaning did not change. It might have been my poor writing that lead DarkSquid to misread, but his implication that I've rewritten the meaning of my answer to agree with him, is disingenuous.

Heath Hunnicutt 2009-11-19 01:46:46

For what it's worth, I'm in no way suggesting that HH changed his answer to reflect mine. It's clear HH knows what he's talking about, and it was my (mis)reading of his original writing which threw me. I'm not sure why he's intent on ascribing evil motivation to me on this forum, but as he says let the history record stand for itself.

DarkSquid 2009-11-19 03:29:59

Is it possible to create a certificate without paying for it? This is a free project that I am working on in my spare time for use by family and friends, so I don't really want to spend any money on it, but I also don't want them to be open to attacks.

Tester101 2009-11-19 15:46:22

Tester - yes, BUT it's not really secure (specifically, you'll be accepting certs from an unknown CA, meaning an attacker can simply create his own cert and you'll never know the difference). To one of HH's original points: what's the real risk here? It's almost a certainty that nobody is going to go to the trouble to attack an app written by you for use amongst your family and friends. For more info on self-signed SSL certs: http://www.akadia.com/services/ssh_test_certificate.html

DarkSquid 2009-11-19 17:55:00

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.

monksy 2009-11-19 00:15:49

ansaurus

tags:

views:

answers:

Should Sockets be secured

related questions