Random thoughts, musings, and tech stuff

04 Dec 2015, 10:00

Share

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.

Why

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

emails

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.

Enter TLS

Transport Layer Security

Previously known as SSL

Usable with any protocol

Establishes an end-to-end channel between two peers

Integrety

Confidentiality

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 TLS

Using standard HTTP libs, replace http:// with https://. Use SSLSocket for socket connectisons.

HostNameVerifier.verify

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

Strict Mode

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.

usesClearTextTraffic

AndroidManifest.xml:

<application android:usesClearTextTraffic="false">

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: