8

Any modern day browser provides feedback to the end user confirming whether or not you are using HTTPS and some basic validation of the cert.

When using a mobile application it seems the end user has no way to verify whether or not their comms are secure. Short of attempting a MiTM using something like ARP cache poisoning is there any way I can verify whether or not a mobile application is using HTTPS?

If the app is using HTTPS and I inject a self signed cert using Fiddler it seems the OS steps in and warns me. At least in this scenario if the app is using HTTPS and someone attempts a MiTM I am warned. However, if the app is using HTTP a MiTM can sit there all day long and as the end user I can only assume it's either secured and the cert is OK or that it's not secured and hope for the best...

Much like app permissions, which can be verified by the user at install time, we could do with a 'secure communications' flag that indicates the OS will not allow unsecured comms to leave the app. Is there such a way to assert this level of security within a mobile app that is not simply an assertion from the developer but something that can be enforced or proven?

Improve this question
2
  • Not an optimal solution, but I just run tcpdump on the router.
    – Polynomial
    Sep 9, 2013 at 11:00
  • There is no cert without TLS/HTTPS, if an attacker is within the broadcast domain of any segment they will see the traffic of unencrypted communications.
    – Eric G
    Sep 13, 2013 at 2:54

3 Answers 3

Reset to default
1

You only need to mount a MitM attack if you intend to decrypt the traffic. if the application is using a standard encrypted protocol (SSL/TLS, SSH) then you can simply record the connection (for instance, using tcpdump) and then feed the result to a descent protocol analyser (i.g. Wireshark) and it will tell you if there is a secure handshake and what options where used.

Improve this answer
2
  • Looking at the traffic certainly won't tell you all the options that were used. In particular, it won't tell you whether certificate verification was done properly.
    – Bruno
    Sep 9, 2013 at 13:12
  • 1
    In fine, NOTHING will tell you if the client or server software did the validation properly except analyzing the application source code (or reverse-engineering it) and that seems to be outside of the scope of the question. Checking the stream will, in case of SSL, tell you what cypher suite was used (encryption and hash algo, block mode, etc.)
    – Stephane
    Sep 9, 2013 at 14:07
0

I'll answer in regards to Android, since I'm more familiar with it.

Most apps will use the built-in HTTP Client libraries, although this isn't guaranteed for fancy or high-performance apps. These Android libraries are not as rich as desktop Java so it is unclear whether the libraries load system-wide settings you could alter (as a root user) and that a force-https option would be available.

In practice you would need to find or create an firewall or forward proxy app that intercepts all outgoing app traffic and injects a HTTP 301 (or 302) instruction to redirect to HTTPS; presumably checking if a HTTPS socket exists for server address. And depending on the library used, there may not be seamless SSL/TLS certificate verification for an app that wasn't expecting to use HTTPS.

Alternatively, just have the custom tool notify the user when an app performs a HTTP request to a non-whitelisted destination.

Preferably this sort of HTTPS-only enforcement should be a feature of the OS, or at least a feature in popular ROMs like CyanogenMod.

As Polynomial mentioned, if your mobile phone routes through a network bridge you control; you can use WireShark or similar to discover what your mobile phone is doing over WiFi. Tcpdump on the phone is possible with right tools and privileges, probably imported into WireShark for better viewing.

Improve this answer
0

I'm not sure about other mobile platforms, but the permission for being able to make HTTPS connections on Android is android.permission.INTERNET, which is actually quite general (it can open any connection).

I haven't tried, but if you know the exact URI in advance, you might be able to use URI Permissions. It's not clear to me whether these apply exclusively to internal content URIs or also to connections made from URLConnection, which might give you the restrictions you want.

Note that this barely matters overall, since what you're asking is visibly not from the point of view of the developer. I'm assuming that your question is about being able to verify that a 3rd-party app only makes HTTPS connections, and that you don't necessarily trust its developers.

  • Even if these URI permissions were usable to enforce HTTPS-only URIs, this would only work if the developers had taken this into account. As it stands, users don't have the ability to override permissions requested by the application (although there seem to be such a feature in Android 4.3 or if you've rooted your phone and installed extra application). In this case, permissions would still not be the right thing to use, since developers effectively grant themselves these permissions: a self-asserting "I only make secure connections" flag would seem pointless, if not also enforced by the OS.

  • If you're in a position to listen to the traffic at the router level, you could at least verify that the application only uses HTTPS traffic at that time. Not noticing plain-text connections during a given period of time is no guarantee that no plain-text connection will ever be made, but that should give a reasonable indication.

  • The fact that you can see an app making HTTPS connections certainly doesn't imply that it is using HTTPS properly. Being able not make certificate errors go away seems to be a common requirement (e.g. on iOS or on Android. For some reasons, answers with insecure solutions seem to be highly upvoted...). While using a self-signed certificate with Fiddler would catch apps that don't verify the certificate at all, you'd also need to use a trusted certificate with a different host name to catch apps that forget to verify the host name.

Improve this answer

You must log in to answer this question.

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