2

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.

5

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 SSLSessionCache and 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.

Summary: use the SSL session ID if you want very transient sessions, which disappear automatically when the browser is closed (the browser process, not just the relevant window). Use cookies for longer-lived authentication. They are not interchangeable; they don't operate on the same time scale.

1

If you are talking strictly about security, SSL is enough.

  1. SSL will prevent a MITM attack (unless the private key of the server is compromised or the negotiated key is disclosed).
  2. 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.

  • 1
    Ensure your server prefers use of cipher suites supporting FS (Forward Secrecy) Even if private key is compromised, your still secure. – webaholik Sep 24 '15 at 4:01
  • You need to a qualify that statement a bit more. Forward Secrecy protects against the scenario where an attacker records the encrypted SSL stream in the hope that in the future they can steal the private key to decrypt the recorded stream. FS ciphers uses an ephemeral key in a way that essentially make the stream undecryptable once the peers forgot the ephemeral key. – Lie Ryan Nov 30 '15 at 16:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.