On November 23 & 24, I attended the first ever Android Dev Summit. The following are notes that I took during talks. I have included the video of the talk as well. Again, these are my notes from the talk, not my original content.
Protecting the network traffic in your app.
- High level TLS, and why you should use it
- Using TLS, checking your work
- Mistakes and misconfigurations
The network is not to be trusted. This has always been true, but especially for mobile devices.
- Devices connect to many different networks
- Coffee shop wifi
- Anyone can run an open wifi
- Devices do sensitive transactions wirelessly
Canonical examples of sensitive traffic
- login for banking
- credit card details
- private personal photos
- sensitive web traffic
- health information
On the server-side, you should secure your traffic. All traffic must be protected.
- Modify non-sensitive traffic (e.g. Time Warner)
- inject exploits
- modify content
- replace images
- Tracking and snooping
Goal the network cannot affect the security of your device.
- Transport Layer Security
- Previously known as SSL
- Usable with any protocol
- Establishes an end-to-end channel between two peers
- Hard part - knowing you’re talking to the right peer
- Safe by default
- Modern platforms have safe defaults and it is just as simple as using TLS.
Using standard HTTP libs, replace
https://. Use SSLSocket for socket connectisons.
ssllabs has a good intro for server-side.
Checking your work
- Hardcoded URLs - what about redirects?
- Server provided - maybe you forget on the server?
- Third-party code - how do you check them?
New feature in Marshmallow.
- Strict mode clear text detection
- usesClearTextTraffic flag in manifest
Uses packet inspection to catch all non-TLS traffic. Useful during development to make sure that all traffic is going over TLS. Some false-positives, e.g. HTTP proxies, protocols with STARTTLS logic, or secure traffic that doesn’t begin with a TLS Hello.
Supported: * HttpsUrlConnection * OkHttp, apache
Why block vs upgrade
- Older devices left out.
- Upgrade logic isn’t always well defined for non-HTTP protocols
Blocking will fail quickly, and obviously. Fixes will be true for all devices.
Mistakes and misconfigurations
Using the default implementation is a good idea. However, you can override the defaults with insecure code.
Legacy servers, with legacy clients choosing what cert to present for a connection.
TLS with Server Name Identifier (2.3+) extension solves some problems around knowing who you’re talking to.
Some internet routing may not support all of the TLS protocols, and may downgrade to SSLv3.
How do you know if you trust this chain of certificates? What ships with your devices?
How can you trust the CAs on the device? (e.g. Lenovo.)
Your app can use its own CA, which may make sense for various applications. However, the example code out there may not be great. Documentation.
What Google’s doing
Vulnerability alerts and blocks
Google is going to be scanning the Play Store, running static analysis on apps, looking for vulnerabilities. They will alert developers, and remove apps that have not been fixed. Here’s the slide that discusses that: