To respond to this, I agree for the most part with Kumar. We could document with something like "if you insist on not using SSL make sure your app is coded correctly to prevent replay attacks" kinda thing.
I will say, SSL certs are not that expensive, at least not in my experience. -r On 4/10/13 10:57 AM, Kumar McMillan wrote: > On Apr 10, 2013, at 12:38 PM, Raymond Forbes <[email protected]> wrote: > >> So, in an effort to eliminate confusion, let's pull out the >> documentation that Kumar and I made to help visualize what is being >> asked. >> >> https://wiki.mozilla.org/Apps/ID_and_Payments#Payments_Data_Flow_Diagram >> >> so, looking at this the one fear I have is it appears we would be >> moving the PIN over the clear. > No, not at all. There is currently a hard HTTPS requirement for any payment > provider implementation (e.g. production is at > https://marketplace.firefox.com/mozpay/ ). The topic of this thread does not > apply to that at all. > > This is about removing the hard HTTPS requirement only for external app > servers. For example, let's say http://myadventuregame.com/ is an app that > accepts in-app payments. Currently we require that app to have an HTTPS url > in order to receive server to server payment notices. That is, the developer > has to purchase a valid cert before she can *make* any money. > > _ > > I am hearing that relaxing HTTPS makes the risk of replay attacks greater if > the app is not coded correctly. However, this seems like something we could > just warn about in the docs with a *big red* banner, no? > > My main concern is that purchasing an SSL cert is going to block some devs > from getting involved with payments but I don't know if that's a realistic > concern or not. SSL certs are not cheap. > > It looks like Facebook apps made this shift too which may have shut out some > indie developers http://www.wpcode.net/fb-ssl.html/ But maybe it's better for > security to force HTTPS on all our apps? > > >> -r >> >> >> >> On Wed Apr 10 09:54:41 2013, Kumar McMillan wrote: >>> On Apr 9, 2013, at 9:15 PM, Fred Wenzel <[email protected]> wrote: >>> >>>> Where does the shared secret come from (i.e., how does it get shared >>>> between app and server)? If it ships with the app, an attacker can just >>>> fish it out of their instance of the app and off they go. If it's sent >>>> over the wire, you need a method to keep it secret; like HTTPS or a >>>> Diffie-Hellman key exchange. >>> It's a shared private secret. The app has a copy that it must keep on its >>> server and the payment provider (Mozilla's Webpay) must also keep a copy >>> securely on its server. All communication is signed with the secret, i.e. >>> no secret is ever passed over the wire, only signatures derived from the >>> secret. So http doesn't really pose a problem here because the signatures >>> are strong (hmac/sha256). The strength can be increased at any time if we >>> choose to without altering the protocol. >>> >>>> ~F >>>> >>>> >>>> On 4/9/13 4:15 PM, Kumar McMillan wrote: >>>>> On Apr 9, 2013, at 5:57 PM, Matt Basta <[email protected]> wrote: >>>>> >>>>>> Correct me if I'm wrong, but if a third party intercepted the JWT for >>>>>> the purchase, they couldn't falsify information in that JWT or somehow >>>>>> create their own fraudulent JWT. >>>>> Correct. This was so obvious in my own head that I forgot to mention it >>>>> :) An attacker can't intercept an HTTP request and *alter* the outcome of >>>>> a payment. The JWT is signed with a secret (shared) key so both parties >>>>> will know if it was tampered with. >>>>> >>>>>> And as you said, user privacy at a high level isn't impacted since >>>>>> there's no personal information in the JWT. Since that's the case >>>>>> (AFAIK), I'd say it's safe to not require HTTPS. >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Kumar McMillan" <[email protected]> >>>>>> To: [email protected] >>>>>> Cc: "Raymond Forbes" <[email protected]> >>>>>> Sent: Tuesday, April 9, 2013 3:29:08 PM >>>>>> Subject: should we support non-HTTPS urls for in-app payments? >>>>>> >>>>>> For a developer to build an app with in-app payments she currently has to >>>>>> >>>>>> 1. host a web server at some domain and >>>>>> 2. that server must accept HTTPS connections with a valid cert. She >>>>>> cannot use a self-signed cert. >>>>>> >>>>>> Is it important enough for the developer ecosystem to relax this >>>>>> restriction and allow HTTP URLs? >>>>>> >>>>>> If a developer self-hosts their domain it is pretty costly to get an >>>>>> HTTPS cert and this would be a barrier to entry. Many services like >>>>>> Heroku, App Engine, OpenShift, etc, will provide HTTPS on a shared >>>>>> domain though. >>>>>> >>>>>> >>>>>> Why HTTPS? The restriction applies to when the Firefox Marketplace does >>>>>> a server to server post with a JWT containing the result of a purchase. >>>>>> This JWT is a blob of JSON that contains info about the product. It does >>>>>> *not* contain user data unless the developer put an email or something >>>>>> in the productData field but that would be weird. In raw form, the JWT >>>>>> is a base64 encoded string of JSON + a signature. >>>>>> >>>>>> Here's detailed info about how notifications work: >>>>>> https://developer.mozilla.org/en-US/docs/Apps/Publishing/In-app_payments#Processing_postbacks_on_the_server >>>>>> >>>>>> Example JWT that would be sent over the wire in plain text (after >>>>>> decoding it): >>>>>> >>>>>> { >>>>>> "iss": "marketplace.firefox.com", >>>>>> "aud": APPLICATION_KEY, >>>>>> "typ": "mozilla/payments/pay/postback/v1", >>>>>> "exp": 1337370900, >>>>>> "iat": 1337360900, >>>>>> "request": { >>>>>> "id": "915c07fc-87df-46e5-9513-45cb6e504e39", >>>>>> "pricePoint": 1, >>>>>> "name": "Magical Unicorn", >>>>>> "description": "Adventure Game item", >>>>>> "productData": "user_id=1234&my_session_id=XYZ", >>>>>> "postbackURL": "https://yourapp.com/payments/postback";, >>>>>> "chargebackURL": "https://yourapp.com/payments/chargeback"; >>>>>> }, >>>>>> "response": { >>>>>> "transactionID": "webpay:84294ec6-7352-4dc7-90fd-3d3dd36377e9" >>>>>> } >>>>>> } >>>>>> _______________________________________________ >>>>>> dev-webapps mailing list >>>>>> [email protected] >>>>>> https://lists.mozilla.org/listinfo/dev-webapps >>>>> _______________________________________________ >>>>> dev-webapps mailing list >>>>> [email protected] >>>>> https://lists.mozilla.org/listinfo/dev-webapps >>>>> >>> _______________________________________________ >>> dev-webapps mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-webapps >> _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
