[Sugar-devel] Auto-authentication for Browse -
martin.langhoff at gmail.com
Sun Feb 8 18:44:37 EST 2009
Hi Simon, Sugaristas,
... any comments on the topic? If I don't hear anything, I'm going to
draft a patch for plan C, aka "how I learned to stop worrying and love
the plain http cookie".
- cheers, martin
On Sat, Jan 24, 2009 at 7:40 AM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> On Thu, Jan 22, 2009 at 12:39 PM, Simon Schampijer <simon at schampijer.de> wrote:
>> c) Auto-authentication for Browse when visiting web-based tools on the
>> XS it has registered to (guest speaker Martin Langhoff)
> First, *apologies* for the no-show -- I got confused between 14hs UTC
> and 14hs EST.
> In terms of what to do with Browse.xo, I have a couple of rough ideas
> to propose. It's a very tentative thing -- and I don't want or expect
> to dictate the implementation. There's been a few discussions verbally
> (at 1CC, and at SugarCamp),
> plus quite a bit on the devel@ list. Might be worthwhile a re-read.
> Here's my outline of opportunities and constraints as I understand
> * We want seamless, magic auto-authentication for the XO when
> visiting web-based tools on the XS it has registered to.
> * We hope this to be low-impact on Browse.xo and 9.1 in general. It'd
> be a big win if the feature works on 8.2 as well. It cannot hamper
> using normal websites.
> * It is better to avoid making it too OLPC-specific. XOs should be
> able to interop with a XS or something roughly like it. (Later down
> the path, perhaps more than one XSish server...)
> * We'd like conventional browsers to able to use the same mechanism
> (but I can add suitable fallbacks on the XS to support non-XO
> * We hope this is low impact on the XS too. It cannot hamper other clients.
> * The XO shares at 'registration' time its local and unique public
> ssh key with the XS. We can use that bit of knowledge clearly and
> without more infra changes.
> * We can change the registration protocol to exchange more data, but
> that will widen the impact of this change significantly.
> * The general idea is to hook a special "in the background" handshake
> when Browse.xo visits a server that looks like an XS. (But for
> example, I don't know what hooks we have in there!). After that
> handshake, which we'd like to be reasonably secure against
> eavesdroppers and replay attacks, traffic falls back to plain http
> with the client having an http cookie. Based on that general idea, two
> approaches have been discussea
> Plan A - HTTPS to the rescue
> Use HTTPS and client certs. On the Browse.xo, either create a client
> cert at first boot or derive one from the SSL priv key we already
> have. Lacking a PKI ( in this case XSs will have self-signed certs,
> and the whole network will often be offline), we will need to grab the
> cert from the
> XS at registration time so we can whitelist it for Browse.xo. This is
> safer, allows us to upgrade later to always using HTTPS if desired.
> It has downsides however
> - we'll have to change the registration protocol, and deal with
> up/downwards compat issues.
> - https is significantly more costly in terms of CPU on the XS
> Plan B - Secure handshake -> http cookie - option
> Assuming Browse.xo can get its grubby hands on
> .sugar/default/owner.key (not sure how to negotiate that with Rainbow)
> then it can perform a simple handshake with the XS over plain HTTP,
> where the XS issues a challenge string that has to be signed by
> Browse.xo with the private key. The XS, having the public key can
> verify the signature. Once it has verified it, it gives Browse.xo a
> traditional HTTP cookie.
> This is cryptographically much weaker because
> - It allows third parties to pose as an XS, and generally play MITM.
> - After the handshake - the interaction continues over plain http. The
> cookie may be set to short-lived, but within its lifetime it is
> trivially sniffed and reused.
> On the other hand, it allows us to just issue an updated Browse.xo
> perhaps even for 8.2.
> Plan C - Simple HTTP cookie
> Bryan Berry mentioned this strategy at XOCamp: at Browse.xo startup
> time create a 'fake' cookie in cookies.sqlite . We could use the
> pubkey -- or a hash of it -- as a cookie. This is trivially MITM'able,
> and trivially sniffable and reused. It cuts to the chase on plan B.
> - - - - -
> Thoughts? Opinions? Code?
> martin.langhoff at gmail.com
> martin at laptop.org -- School Server Architect
> - ask interesting questions
> - don't get distracted with shiny stuff - working code first
> - http://wiki.laptop.org/go/User:Martinlanghoff
martin.langhoff at gmail.com
martin at laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
More information about the Sugar-devel