Hello Mark:
Thanks for the note. I might have been a little naive about
all of this.
First of all, in response to my suggestion about using SSL
combined with password authentication, you suggested problems
wiht session hijacking (I hope this is a good term) as well
as DNS spoofing.
Here is where I may have got a little fuzzy. I had assumed
that when a session is under SSL encryption, the user's
account name and password, as entered in the secure browser
(assuming Netscape), are encrypted at the browser end and
are under cover until they gat at the server.
If they are under cover, along with the rest of the session,
then if the session is hijacked by someone else, I would think
that the person who hijacked the session would have to have
the correct key to decrypt the encrypted session. Now, maybe
I am wrong, but I thought that when an SSL client (Netscape
Browser) initiates a session with sn SSL server; there is
a brief RSA public key encryped transaction to negociate a
DES key for the session itself. Since this is under RSA public
key cover, someone else could not sniff out the DES key. If the
RSA encrypted session were to be hijacked, then the legitimate
client would never get the DES key and the session would be
aborted before the user would even get a chance to enter
the password. The hijacker would not know the password
and could not get into the payroll system even though
he may have stolen a secure web session.
In regards to the DNS hacks, I was under the impression that
with the newer browsers (Netscape 2.??) that a key pair can
be pre-entered into the browser as well as the server, in which
case the browser would only trust that key pair and not any of the
keys that have been set up with the key registries such as
Varisign. If this is the case, then the hijacker's server
(the one which the hijacker diverts the client browser to)
would not have a valid key pair according to the data that
was pre-entered into it ahead of time. I have been envisioning
that the company with the payroll system would pre-issue
key pairs to their employees with instructions to enter them
into their browsers and to only trust those keys and no others
for their payroll transactions.
In regards of host security, I was thinking of drop dead
daemon. Something that would detect any sense of anomoly
within the web server. It could look for any unauthorized
processes (shells, ftp sessions; whatever). Perhaps it could
even communicate with the seb server daemon itself. If anything
is detected, it would go into shutdown and halt the server.
Of course, this would have to have some forgiveness for mistakes
on the part of the users, but if the users have some sort of training,
and know that their sessions were closely monitored, it could be
set up fairly tight. Any URL's passed to the web server which
appear to be attempts to try to run compromised CGI files (which
are know, and of course removed) would signal the drop dead daemon
who would log as much as possible and then shut the machine down.
All of this would require another machine (one inside the company)
to constantly ping the machine to ensure that it is up, and when
the drop dead daemon shuts the machine down, it would immediately
make the appropriate alarms and pages to system administrators.
If a system is halted like this, then no hacks could get into it
and do anything. The two filters would block anything from
going directly through from the outsidd to the inside.
Please, I hope this is clear. I never did well in English.
Mark Allyn
allyn @
allyn .
com
Follow-Ups:
|
|
