I am using Django which is a web framework for Python. I love it but the session handling is cookie-based. Now over SSL I'm sure it's reasonably "secure" but I don't think there is any kind of fail safe for if that cookie gets compromised. I should also mention I am using Apache2 with Mod_WSGI. For each Apache2 session there is an SSL_SESSION_ID environment variable that I can obtain from the root python module. Specifically, my question is will requiring that SSL_SESSION_ID from Apache2 to match the Session_Key cookie in the database (and the clients browser) actually help prevent things like a MITM attack or session hijacking or it is a waste of effort? On the one hand I am thinking it could because the client has no idea (I THINK) about the SSL_SESSION_ID so they couldn't fake it. On the other hand I am thinking that if an attacker could compromise the encryption or the browser enough to get the cookie than they could probably just get the password anyway and start a new session.
The SSL session ID is transient; it designates the "SSL session parameters" that the client remembers about a previous SSL handshake, in particular the negotiated symmetric secret value obtained from the asymmetric cryptography of that handshake. It is kept in RAM only; if the user reboots, or even simply closes all his browser windows, then he forgets the session ID. If you use the SSL session ID as part of the authentication mechanism, then users who close and reopen their browser will have to authenticate with their password again.
If that's what you want, then, by all means, use the SSL session ID. I know of banks who do that for their Web-based bank account management.
Note that if the server reboots, the SSL session ID will also become obsolete: even if it is stored in the database, the rebooted server has forgotten the actual session key (the server, too, stores it in RAM only), and thus will negotiate a new session with a full handshake upon next connection from the client. Also, server memory of past sessions is configurable but often limited in time (with Apache, see the documentation, directives
SSLSessionCacheTimeout). Take also care that client's memory is based on the process: on a PC, closing all windows tends to terminate the browser process; on smartphones and tablets, who like to keep things running for inordinate amounts of time, really killing the process is a more convoluted process (usually, the browser "closes" only when the user runs out of battery).
On the other hand, for less critical sites (in the user's point of view), users tend to prefer it when they authenticate once, and they are "remembered" even across reboots or even browser close. For such a feature to work, there is no avoiding it: there must be some user-specific secret stored on the client side. Cookies are not worse than any other mechanism for that, and they are about the only one which is readily available and compatible with all browsers.
If you are talking strictly about security, SSL is enough.
- SSL will prevent a MITM attack (unless the private key of the server is compromised or the negotiated key is disclosed).
- If someone steals the cookie from a client, then the client PC is compromised and you can do nothing about it. The attacker has full control now and you can add as many tokens/security as you want, but the attacker has full access.
Anyway, you can always use a cookie to identify a user for any reason, i.e.: tracking its activity within different connections, advertisement, counting unique visits, etc.