The security, or more appropriately the lack of it, in online services is generally very badly understood (even by many IT professionals) and implemented even more so.  This is no more true than when it comes to session handling and the use of SSL or TLS.

For example, most webmail systems DO NOT provide any real sort of security when your local network is open (e.g. in most corporate LANs, on unsecured wireless like at the airport or your local cafe).  The reason, you may ask?  Well, at best most webmail systems only secure the login stage when your password is being sent (using the encryption and authentication provided by SSL/TLS protocols, aka HTTPS when talking about web sessions), it then reverts back to plaintext HTTP transfers for the rest of the session, i.e. when you’re reading or sending your emails (the only main-stream exception I know of is Google’s GMail which allows SSL/TLS sessions for everything, but is still weak for other reasons).  This situation is dismal on so many levels, but principally:

• the initial login page was sent over plaintext, so an attacker can modify it before your browser receives it and insert modified code to send (HTTP POST for example) your login details to their own servers first before redirecting you to the official login – SSL/TLS certificate verification probably wont help here as this stage is usually processed very quickly and the attacker can get a cert for their fake domain and servers quite easily – so most users will never notice;
• when you have passed the initial login, then a unique session id is created and is used to identify your browser to the webserver for each further page load (usually via “cookies” which are sent in the HTTP header by your browser) – unfortunately any attacker can also use this unique id in exactly the same manner as your browser (remember it is transmitted in plain text, only the initial login was HTTPS);
• all data you transmit and receive is readable as its in plaintext, so all the mail you read and send is counted here – this is perfect for those attackers who are a bit more lazy or non-intrusive;
• most webmail sites are also vulnerable to a more “classic” attack – when there’s a secure method of doing something and an insecure method implemented, at the same time, in the same system – an attacker is just going to force things back to the insecure method which in our scenario equates to being able to login to your webmail using either HTTP or HTTPS (which is often the case), if port 443, where https is usually served, is blocked by an attacker then most users will just use HTTP logins, see this article on a chip and pin attack for an elegant example of how this idea has been exploited in the past.

Most of these problems can be mitigated by doing the obvious (you would have thought); forcing all transactions with the web server for the secure services to be done via SSL/TLS, set the https-only flag on the cookies, have the secure service on a different domain (or subdomains) and don’t even open port 80 for that domain.  This means your browser will never send your session id in a cookie unencrypted, or it is at least several orders of magnitude more difficult for an attacker to force your browser to do so.  If you want to build in some ancillary assurance, an additional session id in the HTTP URLs and/or permutating the session id doesn’t hurt.  Disregarding the last two addition suggestions, an HTTPS only setup is much easier to confirgure and maintain than a mixed HTTP and HTTPS setup (anyone who has touched virtual host configs in Apache should understand why).  Unfortunately since HTTPS requires a lot more CPU effort (or a dedicated crypto processor), providers usually run a mixed setup to improve performance; which means in practice, usually either all further page loads are done over HTTP which renders the session completely open, or HTTP and HTTPS are mixed which is totally futile.  On a positive note, GMail is generally better than others but still has serious issues, see here and here for details.

These problems are not confined only to webmail systems, its not uncommon for major sites to be vulnerable in a similar manner despite using SSL/TLS (again the problems stem from basic design flaws), see this article at The Register for more information (Bank of America is in there).  For further technical discussion, and from what I can understand also soon to be available software, see some of the posts on fscked.org.

So, when using supposedly secure web applications, caveat emptor.

UPDATED 12th April 2010: Added [] extra meaning in title.