35

There are a lot of mobile apps nowadays with payment gateways support. However, unlike desktop browsers, these mobile apps do not show us an 'Address bar' by which we can identify a HTTPS connection. How can I make sure I am making a payment on a mobile app with a HTTPS connection?

Improve this question
2
  • 3
    Mobile devices come with an official app store. Proper applications should direct you to the app store either directly in app or with an overlay to make purchases because the average person can reasonably expect these to be secure. If they don't do this, you absolutely shouldn't be putting do any purchases or put any personal information into them.
    – user7933
    Mar 14, 2016 at 21:52
  • 4
    Using apps from reputable developers is the best you can do, or use the browser if possible. And no, your local bank isn't always a reputable developer, as I've personally saw a banking app which used HTTPS but failed to correctly verify the certificate, accepting any MITM's cert.
    – André Borie
    Mar 15, 2016 at 0:00

4 Answers 4

Reset to default
11

As @StefHeylen says, you can't, generally. And as @d1str0 says, Burp is one way to see if the traffic is encrypted, if you can proxy the app through it.

It's actually worse than that though - mobile apps don't always only make a single connection to a server. It's not uncommon for them to use HTTP for some parts, and HTTPS for others. They can also do some other tricks which normal browsers don't generally touch. For example, they can certificate pin and refuse to run if they can't make a secure connection to a specific server.

Therefore, it's perfectly possible to have mobile applications that refuse to run when proxied (because they connect to a specific HTTPS server with a specific certificate, which means Burp fails), but which then send payment data through unencrypted means to a different server. The only way to observe this is through packet inspection using something like Wireshark - you'll see a bunch of encrypted data, then some unencrypted data (often JSON or XML) being sent to a different server.

It's also possible for payment data to be sent correctly, then for third party scripts for statistics monitoring (seeing how far users get through forms within the app, for example) to send the same details over unencrypted channels because the app developer hasn't excluded payment fields.

The whole mobile application system is a mess - I'd second Stef's advice to avoid making payments using apps if possible. If you can't, consider using a specific card for those payments, which you monitor regularly for unusual transactions.

Improve this answer
1
  • 4
    And avoid using these apps at all when using public wifi hotspots (whether they are "secured" or not).
    – Thibault D.
    Mar 15, 2016 at 12:01
26

Unfortunately, unless you sniff and inspect your own traffic, you can not... My advice is not to use built-in browsers that do not indicate the protocol being used to handle sensitive information

Improve this answer
4
  • 2
    By that argument, shouldn't you avoid native apps entirely since they don't show whether your data is encrypted in transit or not either?
    – Ajedi32
    Mar 15, 2016 at 18:49
  • 1
    @Ajedi32 I would say "Yes". There's Google Wallet and the Play store to handle those transactions. Why would an app setup it's own payment method?
    – Ismael Miguel
    Mar 15, 2016 at 18:56
  • The problem is many apps do setup 3rd party payment gateways which we can never say for sure are authentic.
    – Adarsh Konchady
    Mar 16, 2016 at 14:51
  • Plenty of things are sensitive other than payment info, too - like session data that would allow a MitM to assume your identity, a la firesheep.
    – Xiong Chiamiov
    Mar 30, 2016 at 21:09
6

Using a proxy tool like BurpSuite will allow you to test whether or not that specific app is allowing or disallowing bad HTTPS connections.

Improve this answer
2
  • although this will be a definitive indiction, it is not a process for the lay-person
    – schroeder ♦
    Mar 14, 2016 at 16:55
  • 3
    @schroeder maybe someone should make an easy-to-use tool for this ? "CheckMyHTTPS: configure the proxy settings of your device to 1.2.3.4, open your app and we'll tell you if it's safe!"
    – André Borie
    Mar 15, 2016 at 0:02
3

In iOS 9 HTTPS in apps is enabled for any network call. You can temporarily bypass it but it is soon to be only HTTPS for all network calls always.

Starting in iOS 9.0 and OS X v10.11, a new security feature called App Transport Security (ATS) is available to apps and is enabled by default. It improves the privacy and data integrity of connections between an app and web services by enforcing additional security requirements for HTTP-based networking requests. Specifically, with ATS enabled, HTTP connections must use HTTPS (RFC 2818). Attempts to connect using insecure HTTP fail. Furthermore, HTTPS requests must use best practices for secure communications.

NSAppTransportSecurity

Improve this answer
1
  • 2
    Apps can still opt out from ATS and I guess more did opt out than turn to HTTPS when ATS was added in iOS9. Searching for ATS in StackOverflow will also show you how little knowledge some developers have about both HTTPS and ATS (For one thing, you can partially disable ATS but most disabled it completely). Apple does not enforce the use of ATS yet.
    – Thibault D.
    Mar 15, 2016 at 12:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .