141–143 of 143 posts
Earlier quoted context omitted.
Of course you can... unless you want to serve ads over HTTP, then indeed, you can't really do that.
All the advertising networks we deal with only offer HTTPS. Hardly any advertising networks support HTTPS.
Earlier quoted context omitted.
The thing that Firesheep brought to people's attention is that the login is not the only thing that needs to be SSL protected. The cookies you get after signing in are often sent in the clear, and that cookie is just as good as your login for gaining access.
It's not the same, because with someone's password you can completely lock them out of their account instead of just acting as them.
So if you really cover all of your bases, and require confirmation at every step, then the least they can do is access your data and generally impersonate you until you log out of that session (which no one does) or the session times out (which it won't, because you're still logged in as them).
It's pretty much the same.
Earlier quoted context omitted.
> Tcpcrypt is opportunistic encryption. If the other end speaks Tcpcrypt, then your traffic will be encrypted; otherwise it will be in clear text. I like that, as opposed to requiring users to have to install some plugin before they can even talk to the server.
You may like it but it really reduces the security. A man in the middle can make it look like you don't speak Tcpcrypt by manipulating the first few packets of a connection. It's the same issue as mixing HTTP/HTTPS - the HTTP parts leave you vulnerable. If encryption is not mandatory then it might as well not be there.
In preventing passive listeners, like Firesheep, this would work 100% effectively anywhere it can work at all. The only way it reduces security is in making people who don't understand MITM attacks feel they're safer than they are - at absolute worst it's like you don't have it installed.