[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.