Session managment, SSL, WSGI and Cookies
What's wrong with your protocol
You might want to consider the following:

Alice contacts your server and obtains an SSL session ID S. A cookie containing H(S) is sent to Alice.
Bob is listening in on the exchange. The SSL session ID is not encrypted, so he can read S.
Bob contacts your server with the session cookie set to H(S). His Session ID is not recognized, but your system will let him in Alice's session anyway (and probably kick Alice out, too!).

The solution would then be to use HMAC so sign the Session ID. But then you might as well just use an HMAC'ed session id in the first place.

A few details:

To know the name of the Cookie he should send, Bob can just contact your server. 
Bob can do the same to get an idea of the hashing algorithm you are using

What's great with HMAC
Session Cookies + HMAC has been proved to be cryptographically secure. HMAC was designed for the purpose of authenticating data. The logic behing HMAC is sound, and there is, as of today, no attack that exist on the protocol. 
Even better, it was proved than an attack on the underlying Hash algorithm doesn't mean an attack on HMAC exists (That doesn't mean you should use MD5 though!).
There is no reason why you wouldn't want to use HMAC.

SSL Session IDs are, at best, useful for load balancers. 
Never implement your own cryptography
You should never, ever, re-invent cryptography. Cryptographic algorithms have been reviewed by (possibly) thousands of people with lots of experience in the field. 
Whenever you feel like you have a better idea, you are probably missing something. Maybe you don't though! But then you should write a paper on your algorithm, and let it be peer-reviewed.
Stick to the standards.
I'm reviewing the possibility and advisability of implementing wsgi-app to browser session management, without using any off the shelf middleware.
The general approach under consideration is to;
Use SSL between the browser and the server.
Expose the SSL session ID to the WSGI or OS.environment, to be used as a session ID to enable application level persistence and authentication.
As the SSL session ID could change at any time if the server+browser handshake again, the idea is to use a cookie to hold a hashed version of the SSL ID generated.
If they handshake and a change in SSL ID is detected (the SSL session ID exposed to the environment does not match the cookie returned by the client), the hashed cookie could be checked to see if it contained the previous known session ID, if it did then we should continue the current session and update the SSL session ID used in the cookie (and stored in a backend db) to be the newly generated-via-handshake SSL session ID. Hence enabling us to continue the session even though SSL session ID's can change under our feet.
The idea, as I understand it, is to let SSL be generating session ID's, and to be doing something that is more secure than relying on just cookies+hmac to hold the session ID.
I would be interested in anyones thoughts on the above process. In principle it seems sound to me, but I have very little experience with this kind of functionality. I have drawn out the flow of exchanges between client & server & wsgi-app for a few scenarios and it appears to work out fine, but I'm not comfortable I've covered all the bases.