That's what I had assumed... It's on their list though so maybe they know something we don't. It's possible that PayPal does non-financial/non-administrative operations over plain HTTP, but that seems risky and silly when you already have the security layer (obviously resources like images are fine over HTTP, but things like scripts and actually server-communication should be over HTTPS)... I think cookies would differ between HTTP and HTTPS sites (as the port would be different) so I don't think cookies would be shared between them. I could be wrong. PayPal is listed as one of the "incomplete" sites so maybe they're just calling out names.

Are cookies readable from any website?

Well, I always use the https firefox plug and one that disables/protects cookies where possible.

Surely the likes of facebook/twitter would be encrypting the cookies and storing the main details in a database, as well as doing the usual stuff like id regeneration?

Cookies are sent in the headers of your HTTP request with Facebook. It doesn't really matter if the cookie is "encrypted" or not if the connection itself isn't because the information in the cookie isn't actually interesting (usually). What is useful is that Facebook (and all Web sites) identify user sessions by the cookie, which means that if you have the cookie to send to Facebook then as far as Facebook knows you are on that user session and can do anything that user can do. I don't have a Facebook account, but IIRC most of the pages are not over HTTPS though. Probably just the login process. In other words, you can't encrypt just the cookie (you can, but it wouldn't do any good). You can either encrypt the entire connection or accept hijacking.

Cookies aren't so much "read" by Web sites as they are sent with HTTP requests in the headers. The beginning of every HTTP request has a header with the basic request information/protocol stuff followed by `name: value` lines. Cookies that match the host's domain or IP (however you are accessing the host) are sent with the request.

JavaScript, which runs client-side, can read cookies, but it only has access to cookies for its same domain. If the <script> tag is inline then it will be for the HTML document that it's embedded in. If the <script> tag is remote (i.e., src attribute) then I think that it applies to whatever host the script was fetched from. I haven't personally confirmed this though.

An extra IP address with my (our) host is only $1/month... Then again, if you encrypt your entire site then you only need one (albeit, the bandwidth costs to encrypt images and the like would probably be more than the cost of an extra IP).

According to info gathered from various sites, Firesheep uses the winpcap library to sniff packets coming through the wi-fi network.

Firesheep reads the cookies sent by the browser to the target site and then uses them for accessing the accounts of the target site.

This means that any account where cookies are used for authentication can be compromised.

According to the info, this is a well known attack method known as session hijacking. Firesheep's originality is that it's the first program to allow any user to do it with a click of a button.

The web will not be secure until everything is encrypted, including DNS requests (of course). But this is something that will never happen, not because of cost (after all, if something is so important, hardware can be made specifically for that; graphics accelerators, for example), but because the authorities will lose the capability to eavesdrop the general public.

http://www.corenetworks.net/

Seems the affordable private servers are sold out.

No. Cookies are always restricted by the top level domain. Optionally they can be restricted by path or sub-domain. You can also limit a cookie to only be set via SSL.

Regarding ^ these lies, if unencrypted, anything you send between client and server is known to the attacker. That includes Flash communication. In theory, you can come up with your own PRNG that is the same between client and server, but you'd have to ensure that both client and server have the same inputs (seeds), which is no easy task. More than likely, whatever algorithm you use would be discoverable by an attacker using the system or by analyzing traffic. And anyway for all intents and purposes it's just reinventing the square wheel. It's encryption. Instead of a secret key you have a secret algorithm. You might as well just rely on SSL, which is tried and tested, instead of relying on your homebrew attempt at security which is likely nowhere near as sophisticated as the standards trusted by the rest of the planet.

All of that is before accepting that not all clients have JavaScript/Flash. I hate sites that are crippled without them. So fucking annoying.

I thought this video from the minecraft thread was rather apt:

Not only does it have Firesheep, it has Firepigs^[1]

Where do you think I got the link?

If http is used, nothing in the headers is encrypted. If https (ssl) is used, then everything is encrypted including the headers.