[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WAS [ProgSoc] Hacked hotmail account? NOW Gmail (in)security
On 05/06/2006, at 7:18 PM, jedd wrote:
No, well, yes, maybe. Yes, in the sense that they are, no in the
sense that they tell you they're about to (or reserve the right to)
and consequently the decision to let them remains yours.
As long as their motto remains "Don't be evil" but their license
agreements say "We still reserve the right to be evil" then on some
level their scamming you.
] There are increasing viable solutions for the server-side
] performance. I'm looking into hardware SSL cards and Solaris' new
] kernel level SSL.
Sure, but I meant that the cost would be enormous if you wanted
to upgrade a farm like Google's to start doing SSL on all their
sessions. Regardless of whether the extra hardware you throw at it
was dedicated SSL cards or just more blades.
Agreed. SSL for just gmail specifically is feasable though. You only
need to the load balances to do the decryption really.
Haven't heard about that new feature in Solaris -- is there really
much benefit from having that in the kernel? I'm surprised it's
not already in Linux 2.6 that's the case. Are they sticking with
SSL, or offering TLS? Hmm .. can't but help feel that Sun is going
through the motions these last few years.
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/inet/kssl/
That's the best resource I could find on the kernel ssl stuff. I felt
the same way about Sun but are really making a genuine turnaround
this year (using some tech that they've been developing for the past
few years). ZFS, Dtrace, kssl, cheap low power AMD sunfires, niagra
etc. All good and innovative stuff.
] I'm thinking of the scenario where a user of this hypothetical
app is
] caught up in something, and some department of the US gov gets in
<snip>
] "here's the data file, it's encrypted though, we'd don't keep the
] keys on file so you'll have to ask the user".
An interesting scenario. The implication is that the user trusts the
provider, but not their (or any) government? If so, that in turn
implies that you'd have a separate provider for each country, and in
some cases, several per country - for those countries that are
blessed
with lots of internal distrust. You hit logistical and marketing
problems here.
From a practical viewpoint, it also implies that the user trusts the
client computer they're working from -- and that comes back to that
other problem -- you can't trust a computer you don't own (in all
senses of that word). And even then, it's a matter of degree.
The key is bandied about at some point, and the data is decrypted
and present on a wire and/or a screen at some other point. Since
you don't own the server, you still have the question of trust.
I guess you could devolve that back to the client entirely, and just
offer a network block style device -- but that makes it tricky if the
client is running from a machine they don't own / trust, and/or can't
install client software on, and in that case, they could just use
a USB drive.
Look, good luck with designing the system .. though I think the
marketing of it will make the design problems pale. ;)
I'm really just looking to hit the 80% solution. I realise no system
is completely secure. But gmail et al are completely insecure. Baby
steps.
"Let's scan that entire organisation's email archives to look for
evidence without telling them"
becomes
"Lets initiate operation 'get the keys' team A is on keyloggers, team
B is on phishing proxies ..."
etc.
It's always going to be possbile to compromise anyone's security with
enough motivation. It's not even worth discussing all the ways to do.
My point is that it shouldn't be easy.
--
(\ /)
(O.o)
(> <)
-- Myles
-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@xxxxxxxxxxxxxxxxxxx
If you are having trouble, ask owner-progsoc@xxxxxxxxxxxxxxxxxx for help.