-----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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla -
http://enigmail.mozdev.org
iD8DBQFFtkxywRnhpk1wk44RAtyRAJ94QdUMcr728GGOsVVgWJ7dQys5lgCgwLvs
EK7q4F5XLq5MScLm8wkRUI8=
=94ZI
-----END PGP SIGNATURE-----