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.langh...@gmail.com> wrote: > On Thu, Jan 22, 2009 at 12:39 PM, Simon Schampijer <si...@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.langh...@gmail.com > mar...@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.langh...@gmail.com mar...@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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel