2

I am looking for a way to encrypt the data sent with the crash from the app to the Fabric servers.

Checking the official documentation I didn't find a method or a property to enable a sort of encryption.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Gabriele Mariotti
  • 320,139
  • 94
  • 887
  • 841
  • IMHO it would be better to use a custom exception handler and encrypt your data on your own, then transmit them to your server, rather than depend on a third party integration for such a delicate situation. – Pavlos Jan 19 '16 at 19:02
  • How would the service work? – David Corsalini Jan 19 '16 at 19:14
  • @DavidCorsalini It is a library which handles the crashes and sends the stacktraces with other data automatically in your dashboard (https://fabric.io/kits/android/crashlytics). – Gabriele Mariotti Jan 19 '16 at 20:00
  • Yeah yeah i know. I mean, how should it work if you encrypt the data you send them? – David Corsalini Jan 19 '16 at 20:02
  • I think that when using ProGuard or Dexguard crash reports get obfuscate by default, since you've to add exception for this to happen, check this part https://docs.fabric.io/android/crashlytics/dex-and-proguard.html#gradle look at the first part "We’ve made it simple to set up ProGuard and Dexguard to automatically upload your mapping.txt file to de-obfuscate your crash reports." – reixa Jan 20 '16 at 12:25
  • @axierjhtjz Proguard obfuscates the package name, the method name... but it doesn't mean to encrypt the crash data. You can also add other info in the crash data sent to crashlitycs. – Gabriele Mariotti Jan 20 '16 at 13:47

2 Answers2

5

What are you worried about?

  1. A hacker hijacking your network data? Well - all Crashlytics communication is done via SSL. If hackers perform a MITM attak on your app, then crash reports are the least of your problems.
  2. Someone reverse-engineering your app? Well - they won't do it through your crash reports - that's for sure. Not when "decompiling" the Java bitcode straight from the APK is so much easier. Your best approach here would be to obfuscate your code using Proguard.
  3. Someone identifying a key component of your app through the crash log? Again - easier via the APK itself.
  4. Someone you don't trust, from your organization, learning stuff about your app from the crash results? You shouldn't give untrusted people access to your Crashlytics data. And if you do - obfuscatre first.

So, IMHO, this is a non-issue.

Community
  • 1
  • 1
Vaiden
  • 15,728
  • 7
  • 61
  • 91
1

You are asking "from the app to the fabric servers". If you mean exactly that then you are already covered, already encrypted and safe over the networks:

From their docs and probably easy to verify:

"All server communication is completed over SSL using packed-binary file format" I'm assuming they actually mean TSL.

If you however mean that the Fabric servers shouldn't be able to understand the data sent (sounds strange), I don't know.

If it shouldn't understand your proguard/dexguard obfuscation (stack traces etc) then don't allow it to get your obfuscation mapping files.

Mattias Isegran Bergander
  • 11,811
  • 2
  • 41
  • 49