Re: Secure Client and Server question...
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


comp.lang.tcl archive

Re: Secure Client and Server question...

From: Adrian Ho <tcl@03s.net>
Date: Tue Mar 14 2006 - 03:19:50 CET

On 2006-03-14, slebetman@yahoo.com <slebetman@gmail.com> wrote:
> slebetman@yahoo.com wrote:
>> Charles Heizer wrote:
>> > Hello,
>> > I'm hoping I culdd get a few opions on this issue I'm having. I created
>> > a very simple listner agent (aka server) which will go on my client
>> > systems. I will listen on a specific TCP port and wait for a wake up
>> > command. It will then go out to my server and download it's job.
>> >
>> > The problem I'm having with is a design thing. I would like to somehow
>> > "sign" the "wake up" command to make sure it's coming from a valid
>> > source. What to others do?
>>
>> The "standard" solution is to use SSL. Partly because there is already
>> a free implementation available in the form of openssl. But a more
>> important reason is that SSL have been designed by security experts to
>> overcome various types of attacks. Unless you yourself are a security
>> expert you are unlikely able to do better if you implement your own
>> system.
>>
>> For more info see: http://www.openssl.org
>
> Ah, sorry, forgot that this is c.l.t. In the context of Tcl ssl is
> implemented by the tls package. Tls is discussed on the wiki:
>
> http://wiki.tcl.tk/2630

It's a wrapper around OpenSSL, so you'll need the latter anyway.

It's also not clear to me if TLS handles server-side authentication of
clients through cert exchanges, which is what Charles would seem to
need. Anyone know for sure?

> Not sure about Tcl's support for SASL so the answer is probably tls.

Tcllib 1.8 contains a SASL package. See <http://wiki.tcl.tk/3230> and
<http://tcllib.sourceforge.net/doc/sasl.html> for details.

Charles, in addition to slebetman's caveat about rolling-your-own, you
should also be clear about what exactly you're trying to protect against
and how your operating environment places limits on your security solution
set (eg. an in-house-only tool can often be less anal about authentication
than one meant for use over the Internet). Your end solution would then
be somewhere between a simple plaintext exchange of fixed secret strings
and SASL-over-TLS...or perhaps something even more Byzantine. 8-)

- Adrian
Received on Sun Apr 30 02:31:28 2006