Protect your Domino applications from Firesheep
The appearance of Firesheep and the resulting awareness is a good thing. The threat posed by "sidejacking" of cookie based authentication has been around for quite a while (not as long as other Fire sheep), just use a packet sniffer like Wireshark or any other sniffing, penetration and Security Tools.
Safeguarding your applications requires securing the transmission lines. There are 3 general ways (note: this distinction isn't technical accurate, but clarifies the options): server/application provided, network provided and user selected.
- Network provided security can be a VPN or encrypted access points (which still leave options to interfere at the end-points)
- User selected are conscious or automated choices to insist on encryption (ZDNet has more details)
- Server/application provided is the ability and insistence to encrypt the whole session, not just the authentication process
- You need to acquire an SSL certificate either by buying one or create your own
- Next you install and activate the certificate on the Domino server. Catch here: you need distinct IP addresses if you have more than one domain to secure. A HTTP 1.1 header isn't good enough.
- Now you need to consider: you you want to secure all databases for all connections or only databases where you expect users to login. If you decide on a database per database approach you can check the database properties and require SSL for a connection (that's a good time to disable HTTP access for databases you don't want to access from the web UI)
- If you decide, that any authenticated connection must use HTTPS all the time you can configure the HTTP server to do so. In your server document you should have switched to "Load Internet configurations from Server\Internet Sites documents" long ago. If not, now is the time.
In the internet site document you can decide to reroute all traffic to HTTPS or just the authenticated access
- Restart your HTTP server
tell http restart