The recent release of the firesheep plugin, which makes it trivially easy for anyone running it to "sidejack" anyone else on the same unsecured public wifi network, highlights how insecure many popular websites (including social media sites such as Facebook) are. Even if the actual login is encrypted, typically subsequent data is sent unencrypted and that includes the key login session cookie. Firesheep allows its users to capture those cookies and use them themselves.
The avowed aim of the developers of firesheep is to convince all websites with personal information to only ever use encrypted web sessions (i.e. https / ssl sessions) so that this information cannot leak. This is a praiseworthy idea but, if implemented, it will kill the market for URL filtering appliances since they will no longer have any visibility into what is being sent.
Curiously enough the bad guys - that is to say the criminals who run botnets and get data back from tojans such as ZeuS - ate already ahead of the game here. They do in fact encrypt their "call home" traffic to frustrate the webfilterers and thus, paradoxically, it would seem that the botherders are rather more secure than major websites such as Facebook.
Ooops. Of course the secret to SSL acceleration has been known for over a decade now so it should not bee too difficult for major websites to move encrypted sessions.
Once that happens, the next question will be how can an organization tell whether a particular HTTPS session is a legitimate one, whether that be the user accessing a financial site or a social site such as facebook or something in between such as gmail. Or alternatively whether that session is a trojan cheerfully reporting back to its controllers the usernames, passwords etc it has just stolen. From a data level the simple answer is it can't - at least not unless the organization is a national government (and even then there are problems).
However one part of the connection is not encypted and can never be - and that is the destination. This is why, using ThreatSTOP, our subscribers are able to block the call home traffic because ThreatSTOP enabled firewalls have a block list of the 1000-2000 currently active command and control hosts and that list is updated every 2 hours with the latest information so it is always current. It doesn't matter what protocol or encryption the bots use, genuine applications have no reason to talk to C&C hosts so the traffic is blocked - and the attempt logged so that the infected machine can be repaired.