How vulnerable is a persistent, unencrypted Internet connection between 2 trusted networks?

the client will maintain a persistent connection to server

No such thing exists.

Each connection -- no matter how long it's supposed to last -- will eventually get disconnected. It may be seconds before the disconnect or centuries, but it will eventually get disconnected. Nothing is "persistent" in the sense of perpetually on.

There is no such thing as a "keep-alive mechanism". It will get disconnected.

"Assume the server authenticates the client upon connection". Can't assume that. That's the vulnerability. Unless you have a secure socket layer (SSL) to assure that the TCP/IP traffic itself is secure. If you're going to use SSL, why mess around with "keep-alive"?

When it gets disconnected, how does it get connected again? And how do you trust the connection?

Scenario One: Denial of Service.

Bad Guys are probing your socket waiting for it to accept a connection.
Your "persistent" connection goes down. (Either client crashed or you crashed or network routing infrastructure crashed. Doesn't matter. Socket dead. Must reconnect.)
Bad Guys get your listening socket first. They spoof their IP address and you think they're the client. They're in -- masquerading as the client.
The client host attempts their connection and you reject it saying they're already connected.

Indeed, this is the exact reason why folks invented and use SSL.

Based on this, you can dream up a DNS-enabled scenario that will allow Bad Guys to (a) get connected and then (b) adjust a DNS entry to make them receive connections intended for you. Now they're in the middle. Ideally, DNS security foils this, but it depends on the client's configuration. They could be open to DNS hacks, who knows?

The point is this.

Don't Count On A Persistent Connection

It doesn't exist. Everything gets disconnected and reconnected. That's why we have SSL.

The client can simply reconnect, the server must respond to the user request with the appropriate error.

False. The client cannot "simply" reconnect. Anyone can connect. Indeed, you have to assume "everyone" is trying to connect and will beat the approved client.

To be sure it's the approved client you have to exchange credentials. Essentially implementing SSL. Don't implement your own SSL. Use existing SSL.

would they have to break into a switch site?

Only in the movies. In the real world, we use packet sniffers.

Sorry I should've clarified that -- I was using 'persistent' with an implicit caveat of 'within the bounds of possibility'. I will create (a) a keep-alive mechanism for the socket (empty TCP payload every 5 mins perhaps) and (b) a handling mechanism for the 'no active connection' eventuality.The client can simply reconnect, the server must respond to the user request with the appropriate error.I'll add some clarification as I think my question's not quite pointing in the right direction. Thanks for the responses so far :-)

boycy 2010-08-13 14:35:42

Ok that provides an alternative (for which I am grateful - and your good justification of it as a better solution will strengthen the case for it), but for my own education I'd still be interested in the answer to the original question - practically is anyone /likely/ to be able to eavesdrop on Internet traffic outside a LAN environment?

boycy 2010-08-13 16:41:32

@boycy: Yes. (1) When your connection is dropped and reconnected it can be spoofed. (2) All unencrypted data is completely visible in the TCP/IP packet stream -- every router sees all of your data in the clear.

S.Lott 2010-08-13 16:49:21

@boycy: The question (above) says "spoof". Your comment says "listen". Which is it?

S.Lott 2010-08-13 16:50:17

By 'eavesdrop' I meant the attacker would be able to see, and hence manipulate, data passing through a network element. I guess my question is about the physical security of Internet network elements. I wanted to ignore the security of the connecting itself (because I feel comfortable with my knowledge there) and look at the security of a longterm connection compared to an on-demand connection.Sorry, I'm not trying to be a pain here, though I think I've achieved it.

boycy 2010-08-13 16:55:48

@boycy: There is **no** physical security on The Internet (in the large). Everything is readable (and indeed actually read) by every router on the net. I'll repeat that, since it seems to confuse you. Everything is readable (and indeed actually read) by every router on the net. What's your question? Please **update** the question so people don't have to integrate a bunch of comments to figure out what you're talking about.

S.Lott 2010-08-13 16:58:56

I am not confused about the concept that every router on the net can read the data and am somewhat offended by the patronising repetition. I do know that a router can read the packets and am not completely new to network programming. I'm (a) sorry that this question is frustrating you and (b) very grateful for your time. I'm obviously finding it difficult to phrase it in a way which elicits the information I'm asking for. Despite rephrasing the question in the last comment I will do so above as you request.

boycy 2010-08-13 17:06:14

@boycy: There is no such thing as a "long term" connection. Why do you keep trying to focus on that?

S.Lott 2010-08-13 17:08:56

So you wouldn't define a network connection which is maintained open and reestablished if dropped longterm?

boycy 2010-08-13 17:12:45

@boycy: It's "on demand". The demand is -- theoretically -- less frequent, but there's no "persistent". All you have is on-demand frequently (i.e., HTTP) and on-demand rarely (your "keep-alive" thing). It's still TCP/IP and it's still on demand.

S.Lott 2010-08-13 17:15:13

I know it's not a technical term, but I'm trying to contrast between a connection open for a short amount of time and one open for a long period of time.Regarding the packet sniffing mechanism, where can you sniff the packets if you don't break into a switch site?

boycy 2010-08-13 17:27:18

@boycy: There's no distinction between short and long duration. They're both "on-demand" with the exact same vulnerabilities. The Same. I would sniff packets through my Cable TV provider because I'm too cheap to actually contract with a Telco for a proper T1 or DS1 connection.

S.Lott 2010-08-13 17:46:22

So you're saying that if you have a cable connection then the immediate network element outside your house is a hub not a switch?

boycy 2010-08-13 17:55:52

And thanks, I guess "The Same" answers my question, though I feel far more stupid than when I asked it..

boycy 2010-08-13 17:57:10

And as far as the distinction goes, I know the protocol doesn't give two hoots about it, but let me explain why I thought it might be important by way of analogy.Compare the difference in home security between someone who only unlocks their door when they want to go through it, and someone who leaves their door unlocked all the time. Not exactly a watertight analogy but it may help you understand why I asked the question

boycy 2010-08-13 18:01:44

"is a hub not a switch" too subtle a distinction for me. Download `satan` or other Black-Hat network analysis/hacking software. The Internet itself is very wide open. The individual sites (behind firewalls) are not so open. But sniffing unencrypted traffic is done by kids with open source software. They're called "http://en.wikipedia.org/wiki/Script_kiddie" and the net's full of 'em.

S.Lott 2010-08-13 18:02:03

@boycy: "Not exactly a watertight analogy". Not even close. The analogy is someone who opens their door frequently vs. rarely. Either way, **the door must be opened**. You can try to do it less often, but that does not change the essential vulnerability. It only changes the frequency.

S.Lott 2010-08-13 18:03:07

Not sure I understand; the distinction is important surely? If you connect out to a hub, you will receive packets not destined to/from your public IP. If it's a switch, then you will only receive packets to/from your IP. SATAN seems to be a port scanner with greatly extended functionality, which would allow you to scan someone, but not to receive packets from a switch which aren't destined for your network.No, my original analogy was actually closer to what I was asking than yours. But thanks.

boycy 2010-08-13 20:33:01

@boycy: "the distinction is important". Not really. The script kiddies can't all be buying proper routers from telcos. (I suppose they **all** could be buying routers, but I doubt it.) This leads me to conclude that at least one cable provider allows script kiddies an unreasonable level of access. Additionally, there are any number of tunneling protocols as well as unsecured routers. The "hub/switch" business doesn't have any **practical** significance, since hacking goes on irrespective of that distinction.

S.Lott 2010-08-13 21:03:37

ansaurus

tags:

views:

answers:

How vulnerable is a persistent, unencrypted Internet connection between 2 trusted networks?

related questions