-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gregory Maxwell wrote:
On this subject... Wrapping the login site via SSL sounds like a dandy idea, and it sidesteps the whole mess of cert issues if with SUL we were to use a single login portal domain.
However, then we've just pushed the problem back to session cookie theft. Sure, it would still be an improvement since a passive attacker (at say Wikimania...) couldn't sit back and gather passwords, but better still might be possible.
What the current industry best-practices with respect to binding session data to a client's IP? Do web browsers switch IPs too often for this to be acceptable (AOL?)?
My impression is that the most likely actual scenario for network sniffing is an open wireless network behind a NAT -- so everyone will have the same IP on the outside anyway.
Binding to IP probably protects more against cookies grabbed via XSS (but then you can probably do your nasty things in JS).
AOL is a problem, with the switching of the IPs...
At some point it might make sense to talk about all logged in user sessions being SSLed... the overwhelming majority of the computational load of SSL is the RSA stuff for signatures which would need to happen once per login if we went the SUL login page behind SSL route.. After that it's just symmetric crypto which isn't astoundingly expensive.
Were we to move logged in users into SSL all sorts of threats just go away.
That gives me warm fuzzy feelings, if we can in fact swing it cleanly. :)
Of course there is the little matter of plain squid not supporting SSL offloading like some of the commercial reverse proxy / acceleration solutions which would have to be resolved...
Details, but details to think about.
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)