Re: payswarm vocabs http vs https

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