[Sugar-devel] Auto-authentication for Browse -

[Martin Langhoff]

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:
>> ===Topics===
>> 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
> them
>
> * 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
> users...)
>
> * 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?
>
> cheers,
>
>
>
>
> m
> --
>  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
 - http://wiki.laptop.org/go/User:Martinlanghoff