>DISCLAIMER: I am not a WWW / CGI expert. I actually know squat about it.
Ok, I am not either.
>I can actually see arguments for both of your proposed architectures.
>
>First of all, however, these "encrypted sessions" - are we just talking SSL
>or some other devious network layer encryption? If it's the latter (like
>IPSec etc etc) then you should go and read the recent thread(s) about
>network layer encryption and NAT.
It is standard DES with a random session key. The encryption is
implemented - according to vendor information - at an extra layer placed
between the APPLICATION and TRANSPORT layers on the TCP/IP stack. Just like
SSL.
>If t's SSL then you'll be fine. (I'm a
>little hazy on these "RSA Keys"...you mean certificates, or what?)
Yes, that�s it. The authenticator software authenticates users using
certificates and a challenge/response protocol (the DES session key above is
also generated and exchanged on this phase).
>One question that you don't raise is - where is the data for these private
>webpages coming from?
It is coming from an app server that will be on one of the trusted networks
(not even the same trusted network as the private web server).
>From your mail I could be forgiven for thinking that
>it's self contained on one server and generated by CGI. If so, cool. If it
>has to talk to some other database somewhere, things might suck.
Yes, it needs to talk to the database on the other trusted network.
>So...irrespective of where you have your private content, there's a
security
>principle which probably has a fancier name than "Don't put all your eggs
in
>one basket". In other words, I would have the app / www server for the
>private content on a separate box.
Indeed they will be different boxes.
>Your basic tradeoff is this: Private box inside network is really easy to
>administer and really easy to get it talking to the database. However, if
>the private server gets screwed thn you've lost all the information
>(potentially) in your private network.
Well, the real data will be on the app server.
>WWW server in DMZ can be a pain in the butt to administer and ranges from
>tricky to damn near impossible to get talking to the database securely.
>Remember to think about what happens if someone is camping in your DMZ with
>a packet sniffer (running on your compromised public WWW server) - can they
>see all your "private" DB transaction in the clear?
No, definitely the private web server WON�T BE on the DMZ. Yesterday I�ve
been told this server is going to host DNS and MAIL services too.
This way, even if someone manages to run a sniffer on my compromised web
server on the DMZ, they�ll only be able to see the connections coming from
the Internet which will all be encrypted (except for DNS and MAIL) with DES
anyway.
>There's a great deal of paranoia concerning WWW servers that do _anything_
>with CGI. Think carefully about your choice of webserver platform. Most
>people seem to advocate assuming that they _will_ be compromised and doing
>your risk management from there.
you are right, CGI is really a big headache. Imagine CGIs written in MS
VB... the server will be compromised as long as someone is able to run one
of these CGIs. LOL.
Thanks a lot for your help.
Regards,
F�bio.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
