stacks interacting over LAN? (newbie)

Frank D. Engel, Jr. fde101 at fjrhome.net
Wed Dec 1 12:51:27 EST 2004


On Dec 1, 2004, at 12:27 PM, Richard Gaskin wrote:

> Björnke von Gierke wrote:
> > On Dec 01 2004, at 11:02, sims wrote:
> >> I'm curious about what security concerns that a chat (or sockets in
> >> general) might open up for the user and what (if any) precautions
> >> need to be taken.

Intercepted messages, forged messages, corrupted messages, ...

> >
> > This of course varies with the implementation, but talking about
> > chatrev, I can assure you that there is no security risk whatsoever
> > for the client. This is mainly due to the fact that the client never
> > opens a port.

Not true.  First of all, clients open a port in order to connect to the 
port on the server.  Both ends of a socket connection use a port.  The 
one at the server end accepts connections from other ports, while the 
one at the client end serves as a means by which to manage a connection 
to the server's port.

Also, there is always a security risk in everything done in any way 
with anything, and security is more than just preventing root access to 
a UNIX box and preventing transmission of unexpected data.  Your chat 
client does not control the protocol drivers in the operating system.  
Opening the client port may introduce vulnerabilities in the form of 
bugs in the underlying TCP/IP suite used by the operating system -- 
even though your code might be perfect, this could still create 
security risks to the client machine.

Additionally, depending on your chat client's protocol, there is the 
possibility that messages could be forged or intercepted.  SSL or other 
encryption packages can help to reduce, but not eliminate that risk.

>
> How does it create a socket connection without opening a port?
>
> > However this is about to change, as we are incorporating file
> > transfer (Which needs a accept connection at one end). Still,
> > the opened port is occupied by rev and closed swiftly after
> > finishing transfer, and because of that you won't get any
> > malicious attempt trough.

Not guaranteed.  If someone between the two systems on the connection 
intercepts the request to transfer a file, he could beat the other 
system to opening the connection to that port and send malicious or 
invalid data to it.  So instead of the screen saver user X expected, 
that EXE file installs a virus or some kind of spyware...

When one computer requests a file from another, the one granting the 
file transfer might have its attempt to send intercepted by someone in 
between, and the one intercepting the attempt could receive a copy of 
some sensitive document...

>
> I'm no security expert, and this may be just a case of my own 
> ignorance getting the best of me, but for my own wares I would be very 
> careful about offering such broad assurances for anything involving 
> network software.  Maybe "unlikely to" is more accurate than "won't".
>
> Anytime one computer talks to another there are at least two risks:
>
> - One of the computers may be in the hands of someone
>   with malicious intent
>
> - While in transit the data may be intercepted
>   by a malicious third party
>
> The beauty of TCP is that it's a ubiquitous standard that's been 
> around for a long, long time, so everyone uses it and all tools can be 
> interoperable with it.
>
> The downside of its ubiquity and maturity is that there are people out 
> who devote a sad majority of their lives to mastering TCP specifically 
> to destroy other people's constructive activity.  Most of those 
> misanthropes are far smarter than me, and have a deeper knowledge of 
> TCP and its implementations across operating systems than I'll ever 
> have.
>
> I believe that absolute security is not achievable, and that the best 
> we can aim for is to slow down exploits.  That's no so bad, and is 
> good enough for businesses and even governments to go about their 
> business more productively than without software.
>
> But I would be wary of giving people the impression that a software 
> provides absolute security.  Instead, communicating what it does to 
> protect itself may be all that's needed for the user to make their own 
> risk assessment.

True.  Security is relative to the task at hand, and to the perceived 
desirability of breaking that security.  This is definitely a moving 
target.

>
> -- 
>  Richard Gaskin
>  Fourth World Media Corporation
>  ___________________________________________________________
>  Ambassador at FourthWorld.com       http://www.FourthWorld.com
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
-----------------------------------------------------------
Frank D. Engel, Jr.  <fde101 at fjrhome.net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten 
Son, that whosoever believeth in him should not perish, but have 
everlasting life.
$



___________________________________________________________
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com



More information about the use-livecode mailing list