Re: request for comments : slush

From: Nico Kadel-Garcia (nkadel_at_comcast.net)
Date: 02/21/04 

Date: Sat, 21 Feb 2004 14:04:06 -0500

"Richard E. Silverman" <res@qoxp.net> wrote in message
news:m2n07e8iyc.fsf@darwin.oankali.net...
>
> Security protocols are difficult to engineer, hard to get right, and take
> a long period of deployment, expert review, and revision before they
> mature and become trusted. Ad-hoc protocols invented by non-specialists
> for specific purposes are almost always very bad (for a perfect example,
> consider WEP). Rather than rolling your own, you would be better served
> by adapting an existing, tested protocol for your use. For example:

Take Richard very, very seriously on this, especially since the data
transfer itself of SLUSH is unprotected.

You use SLUSH to connect to your school's servers and run software and
authenticate yourself? Great. You then connect back out via SSH client, FTP
client, web client or mail client on that server? Kiss any passwords typed
this way "buh-bye!", because the cracker wanna-be down the hall at your dowm
who plugged into your local hub and is monitoring your traffic or who
backdoor programmed a switch to monitor and echo traffic to an analyzer now
has your passwords, and uses the same password you used for one to break
into your other sites because you're the sort of careless user who types
passwords over unencrypted channels, therefore *of course* you use the same
password everywhere.

If you must have significant data transfers in a server-class facility, such
that full session encryption is an unacceptable load, it's perfectly
reasonable for the server and client to run tools that synchronize an
un-encrypted but channel protected FTP or HTTP file transfer by allowing
only connections on the un-encrypted channel for the designated host and
client. This technique is quite common for industrial use: many such
industries also lightly encrypt the package

If you need live interactive sessions and are actually overloading your
servers with SSH encryption, you may need to revisit your hardware
capabilities: almost no server hardware/OS can survive more than 1000
simultaneous connections in *any* case, encrypted or not, so you may not see
the benefit you expect....

Relevant Pages

  • Re: Socket Server with Encryption help
    ... Before the client ... Authentication protocols are fiercely difficult to get right. ... by Needham and Schroeder "Using encryption for authentication in large ... Client connects into Server and Server accepts the connection. ...
    (microsoft.public.dotnet.security)
  • Question on client/server application
    ... (one will act as a simple TCP server and the other will be a simple ... TCP client). ... What is the simplest way for me to implement a secure connection ... There are plenty of encryption libraries out ...
    (comp.lang.pascal.delphi.misc)
  • RE: Implementing RSACryptoServiceProvider *and* JavaScript
    ... JavaScript: hashing, synchronous encryption, and asynchronous ... This will enable me to ensure security between the client ... Send these back to the server. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: RDP Data Encryption Error
    ... If we make a remote connection to the server at work and then RDP into one ... we get this "encryption error" after a few seconds. ... the client will drop the connection ...
    (microsoft.public.windows.terminal_services)
  • RE: Help Newbie..Upload file from SQL Server
    ... Enable SSL Encryption for SQL Server 2000 with Microsoft Management ... Steps to Use to Install a Certificate on a Server with Microsoft Management ... Steps to Enable Encryption for a Specific Client ...
    (microsoft.public.sqlserver.programming)