Actually, I did say a bit about the network. Its a windows network, (windows 2003 server, I believe) with the exception of the database servers which are on Linux.
How is it vulnerable after the data is unencrypted? As I stated, the encrypted data is downloaded to a desktop application over SSL and THEN unencrypted via the private key on the desktop users system. (a location not where the servers are).
The data is fairly secure on the way from a users browser to the webserver (via SSL) and even if some program like Ettercap can capture encrypted data .. well, its encrypted.
My biggest worry is the unencrypted data, at the webserver, before I've run it through GNUPG (public/private key encryption at 2048 bits).
So ... how do I protect the pre-encrypted data in memory? or is there no way an ourside program can access data in RAM that perl is using?
| [reply] |
Yes, you're correct: if the data stream is unencrypted on the client's machine, that's pretty secure, although you might want to investigate the encryption scheme, local firewalls, etc..
So at the risk of oversimplifying: there's a WAN side and a LAN side. In most networks, the LAN side is highly controlled; that does not sound like the case in your situation. I suggest that you imagine that anyone on the LAN side is capable of running ettercap. I suggest that you run ettercap on the LAN side and see what shows up. You might be OK; you might not be OK.
I think the data in RAM is pretty secure, again with caveats about firewalls, etc.
| [reply] |
Update: Okay, my first stab at a reply was too 6-o'clock news sensational... here it goes again.
Since this is a shared IIS server, I wouldn't consider data in RAM safe. At the very least, how do you ensure physical security of the server, console access, remote logon? Okay, this is a problem faced a lot though, and generally accepted practices prevail.
Supposing ActiveState Perl is installed, there are 2 ways Perl CGI can be run: in-process and out-of-process. Perl for ISAPI handles CGI's in-process and perl.exe handles them out-of-process.
Perl for ISAPI's perldoc says:
The main advantage of PerlIS over perl.exe is that PerlIS runs as a DLL in the web server's process space. Because Win32 platforms set up a protected memory space for each process that is started, there's a lot of overhead in starting a new process or program. Passing scripts to an interpreter, such as perl.exe, requires starting a new process for every script, which gets expensive in terms of system resources.
DLLs, on the other hand, don't need their own process space; they use the space of the process that calls them. They don't require nearly as much overhead to start, and once loaded they stay loaded until the calling process ends. PerlIS therefore runs Perl scripts with a quicker turn-around time than perl.exe.
Draw your own conclusions (from extensive testing).
There is also the possibility of a trojan perl.exe being installed on the server... how can you verify it? Or a trojan cgi script (if the ftp password is snagged--or file permissions are weak--or the shared admins are criminal). Yuk.
I would be paranoid... but I usually am. YMMV.
--Solo
--
You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
| [reply] |