Lesson 3.30: Network security: HTTPS, trusted certificates and pinning
An app talks to its servers over networks you don't control, so every connection must use TLS and trust only the right certificates. Android's network security configuration controls this: whether plain HTTP is allowed, which certificate authorities are trusted (the system's, or also ones the user installed), and optional pinning to specific keys. In the lab you read Northwind Shop's configuration, find cleartext allowed for staging, user-installed CAs trusted in the release, and a pin set that expired over a year ago; you see the token travel over HTTP in the debug build's log; and you put a corrected configuration into the source.
18 min
You will learn to
- Explain cleartext traffic, trust anchors and pinning
- Read a network security configuration
- Spot an expired pin set
- See cleartext traffic in logs
- Apply a corrected configuration
Key terms
- Cleartext traffic
- Unencrypted connections such as http://.
- Trust anchors
- The CAs whose certificates the app accepts: system CAs, and optionally user-installed ones.
- Certificate pinning
- Accepting only certificates whose public key matches a known hash.
- debug-overrides
- Network config section that applies only to debuggable builds.
- Machine-in-the-middle
- An attacker who relays and reads traffic between the app and the server.
← Hashes, reputation and variants · All lessons · IPv6: the next generation of addresses →