Browsing through security issues

Security is expensive. It’s expensive in terms of complexity, management and non-ease of use. It’s also expensive in terms of the processing power required. But attempts to minimize the impact of the latter on Web servers are now affecting the very security that is being sought.

Web security is pretty good stuff. The basic idea is that you want to set up secure communication between yourself and a server that you are sure is the right one. At the same time, the server wants to be sure that it’s talking to you and not someone down the street.

The server has a digital certificate your browser uses to be sure it is communicating with the right server. You authenticate yourself to the server with your digital certificate or with a logname/password combination. Thus, the server knows who you are. You, as a user, authenticate yourself to an authenticated server – just the right level to be securing – and the communication is encrypted. What more could you want?

By the way, I say Web security is at “just the right level” because the authentication is taking place at the user level and not the system level, as is the case with many VPN products and services.

VPNs can be used between firewalls, in which case the communication inside the firewalls is open to eavesdropping, and the identity of the servers and users is not assured. VPNs can also be used between remote computers and a firewall. The result here is not much different – insecure internal communications and no server authentication. In addition, if the remote computer is compromised, the first line of corporate defence is breached.

But there is a disturbing, if understandable, trend that undermines some of the security of a secure Web environment. This is the movement to separate front-end processors that are used to off-load some of the computing-intensive work from the Web servers. These front-end processors mimic the server you’re trying to connect to. They have a digital certificate for that server, so your browser thinks it’s talking to the actual server. The front-end processor does the encryption and decryption, and communicates with the actual Web server using unencrypted datastreams.

Since this is all in a data centre, one might think that it’s all OK security-wise. But it’s not. The data is now exposed to eavesdropping, where it previously had not been.

Also, if the front-end processor is compromised, all the servers it front-ends for are compromised. But more importantly, you as a user can no longer be sure what you are talking to. Transparent proxies, Network Address Translation systems and firewalls have already compromised the original end-to-end Internet model, and I guess this is just another little step along the path. But I don’t have to feel good about it.

Bradner is a consultant with Harvard University