- No Safety in Numbers
- No Web Server Is Unbreakable
- Watching the Exits
- Securing the Exit-Control Box
- Extra Security Features of the Exit-Control Scheme
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Securing the Exit-Control Box
The astute reader will note that the separate box architecture for exit control presents a problem for secure transactions that use SSL to protect the content. Since everything is encrypted, there's no way for the exit-control box to check the fingerprint of content as it travels through. There are two solutions to this problem:
Share the SSL state between the server and the exit-control box, so that the content can be decrypted with the session key. This has several practical limitations, and is likely to adversely affect performance.
Terminate SSL in the exit-control box itself. This means that the box will need to run additional code, and it will have to contain the secret key of the server. While this isn't ideal, it's consistent with the idea of separating the security aspects of the system from the functionality. If the SSL is terminated in the exit-control box, the secret key is not needed on the web server, so when (not if!) the server is broken into, the secret key will not be compromised.
Is this just trading off security of the web server for security of the exit-control box? It's an interesting question. In security, we view complexity as the enemy. The more complex something is, the harder it is to secure it. The nice thing about the exit-control strategy is that, while the web server is bulky, runs CGI scripts, and often has user logins, the box watching the exit can be kept simple, run a hardened OS, be monitored closely, and thus be protected more easily. In fact, in its product, Gilian took an additional step of not making the box addressable, so it doesn't even have an IP address.