Allow TLS/SSL encrypted use of LiveJournal (not just logins)

[pne]

Title
Allow TLS/SSL encrypted use of LiveJournal (not just logins)

Short, concise description of the idea
Now that cookie-capturing attacks (e.g. Firesheep) have become easy to use, it would be good to be able to use LiveJournal through an encrypted connection.

Full description of the idea
It's been possible to log in through an encrypted connection for a long time, and there have been proposals to make this easier (e.g. http://community.livejournal.com/suggestions/838706.html).

However, only very few pages are available via SSL - essentially, only the login page.

This lets people log in without anyone being able to sniff the password, but still exposes the login cookie to all and sundry who happen to be listening on the same network - and now that things like Firesheep are out, that becomes fairly easy.

While someone with your login cookie can't change your email address or your password (since those require knowing the current password), they could read others' friends-only entries, post spam or advertisements in your journal, delete all current entries, or probably wreak many other kinds of havoc.

For this reason, it would be good if there were an option to use LiveJournal completely over an encrypted connection (SSL/TLS).

Ideally, this means not only site-scheme pages or those on www.livejournal.com, but all of them: including community.livejournal.com and exampleusername.livejournal.com.

I don't know enough about the separate-cookie-per-subdomain scheme that was implemented a while back to know exactly how much damage can be done with a cookie for exampleusername.livejournal.com, so it may be sufficient to have www.livejournal.com be encrypted and the other subdomains remain as they are now. Someone more familiar with LiveJournal's security setup should evaluate this.
An ordered list of benefits

• Greatly reduced risk of cookies being captured easily by readily-available tools over shared networks (e.g. open wi-fi).
• Even less chance of credentials being hijacked in other ways.

An ordered list of problems/issues involved

• Explicit/absolute links to http://www.livejournal.com/example.html (i.e. with "http" in the link) would "break" since they would go to the unencrypted site.
• Ads would have to be hosted on a server allowing SSL connections or you'd get lots of "this page contains a mixture of secure and insecure content!" warnings on browsers.
• Encryption takes up more processor power on the web servers than unencrypted connections - may need to buy more (or beefier) machines.
• LiveJournal may be tempted to offer this only to paid accounts, meaning that people who don't want to (or can't afford to) pay will have less security available to them. There'll be a two-class society: those who are (comparatively) secure and those who are told "So don't use open wi-fi, then".
• I'm not sure whether encrypted pages can be cached - this may cause more "hits" on the web servers if requests can't be fulfilled from local caches any more.
• Greater feeling of security may cause users to act more recklessly in some ways, undermining the intended effect.
• Slower page-load times as both web server and the user's browser have more work to do on an encrypted connection.
• Extra cost for a wildcard "*.livejournal.com" SSL certificate if one isn't already available. (I'm assuming that separate certificates for each subdomain is completely out of the question, given how many thousands of users LiveJournal has.)