- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Fri, 25 Jan 2013 21:02:11 -0500
- To: Web Payments <public-webpayments@w3.org>
On 01/25/2013 10:08 AM, David I. Lehn wrote: > On Fri, Jan 25, 2013 at 9:12 AM, Melvin Carvalho > <melvincarvalho@gmail.com> wrote: >> Apologies if this has come up before, but I am wondering if there >> is a possible MITM attack surface where payswarm vocabs are under >> http, rather than, https. >> >> Is this a concern at all? Yes, we're concerned about it. We ran through a list of threats some time ago and found one successful attack vector with a number of mitigations. We need more eyes on the problem. > This was brought up at Digital Bazaar and maybe made it on the > telecons. We haven't thought through all the details yet but I think > there could be an issue. Maybe something with reversing the source > and destination? We have a couple of scenarios that we considered: 1. The PaySwarm Authority is duped into loading the bad JSON-LD context. 2. The Seller is duped into loading the bad JSON-LD context. 3. Both Authority and Seller is duped into loading the bad JSON-LD context. 4. An http-based, seller-defined context is overlayed on top of the valid JSON-LD Context, redefining source/destination. #1 doesn't happen because any well-implemented PaySwarm Authority should /never/ load the JSON-LD context from an HTTP site. Ours doesn't, we should probably put a warning about this in the spec. #2 Would result in the PaySwarm Authority verification of the Seller signature to fail (since the source/destination would be swapped, the digital signatures would fail verification). #3 can't happen if the PaySwarm Authority doesn't load the JSON-LD context from the Web (invalid digital signature, again). #4 is dangerous. JSON-LD does have a feature where it allows you to load any other context from the Web. Those contexts can override 'source' and 'destination'. There are a few mitigations to the #4 attack: 1. Don't load http-based contexts from the Web. PaySwarm Authorities would have to download and vet the context before white-listing it. 2. Terms from HTTPS-based JSON-LD contexts can't be overridden by terms defined in HTTP-based JSON-LD contexts. This would mean that an HTTP-based context could never override the values for source/destination. 3. A PaySwarm Authority should reject all HTTP-based JSON-LD contexts. > I imagine it would be a challenging attack to pull off in practice. > The main reason we are using http://purl.org/payswarm/v1 right now > is that purl.org doesn't support https. Or at least they didn't > last time we checked. Manu, do you know about this? I've asked purl.org to do this numerous times, and they've been non-responsive. We've also been waiting for them to authorize the http://purl.org/security -> http://payswarm.com/vocabs/security entry for years, no response. > I'm not sure what the best solution is. We could stop using > purl.org until they are fixed but we'd lose the benefits of their > redirection service. Or we could come up with some other tricks like > adding a @context hash property so you can verify you are processing > with the proper data. Other suggestions? Yeah, we did also discuss a context hash value, but that seemed like placing the JSON-LD Context security stuff at the wrong layer. I'll try calling OCLC, the folks that run http://purl.org/, again and tell them that we'd be happy to buy an SSL certificate for them. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) President/CEO - Digital Bazaar, Inc. blog: Aaron Swartz, PaySwarm, and Academic Journals http://manu.sporny.org/2013/payswarm-journals/
Received on Saturday, 26 January 2013 02:02:45 UTC