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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel