On Apr 10, 2013, at 1:01 PM, Raymond Forbes <[email protected]> wrote:
> oops, yup, you would think i would look at my own diagram. :) > > To be clear to everybody, Kumar is talking about allowing the > connection between the 3rd party app and the client (e.g. the phone) be > non-ssl. Actually, it's even better than that. I'm talking about allowing a non-ssl connection between the 3rd party app and *the payment server* (e.g. Mozilla), not the phone. If it were the phone I'd be way more concerned. It would be hard to put a MITM proxy in front of Mozilla's servers. But there could be exploits in the 3rd party app server. > From what we have diagrammed the only data being passed is > the JWT token. (I realize that was established but hopefully this > diagram helps make it more clear for people) > > -r > > On Wed Apr 10 10:57:53 2013, 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
