OWASP Mobile Top 10: M3 Insecure Transport Layer

This presentation covers OWASP Mobile Top 10 Risk M3: Insufficient Transport Layer Protection, providing a thorough walkthrough of transport layer security fundamentals, known SSL/TLS vulnerabilities, and common insecure implementation patterns in mobile applications. Anant Shrivastava explains the OSI model’s transport layer, TLS certificate chains, protocol version weaknesses from SSLv2 through TLS 1.2, and delivers platform-specific prevention guidance for both Android and iOS developers.

Key Topics Covered

• Transport Layer Fundamentals: OSI Model Layer 4 provides end-to-end host communication using TCP and UDP protocols, identified by IP:Port pairs. The presentation covers TCP and UDP header structures to establish foundational understanding of network communication.

• TLS/SSL Overview: Transport Layer Security (formerly SSL) uses X.509 certificate-based asymmetric encryption. The latest version in use at the time was TLS v1.2, with TLS v1.3 in draft since July 2014. Certificates are issued by Certificate Authorities (CAs) and follow a chain of trust to establish website identity.

• SSL Version 2 Vulnerabilities: Designed in 1994 by Netscape, SSLv2 suffers from identical keys for authentication and encryption, weak MAC construction using MD5 susceptible to length extension attacks, no handshake protection allowing undetected MITM downgrade attacks, TCP connection close for data termination enabling truncation attacks, and single-service/fixed-domain certificate assumptions.

• SSL 3.0 and Later Attack Surface: SSLv3 has weak key derivation relying on MD5, and is vulnerable to renegotiation attacks, BEAST (CBC ciphers), CRIME and BREACH (compressed connections/SPDY), Lucky13 (timing attacks), RC4 weaknesses, and implementation bugs like Apple SSL goto fail, Heartbleed, and GnuTLS failures.

• Common Insecure Mobile Implementations: Using known weak ciphers or protocol versions, communicating via self-signed certificates while ignoring warnings, securing only specific portions of communication, not validating the certificate chain of trust, and mixing TLS and non-TLS content on the same page.

• Chain of Trust Issues: Failure to validate that the entire certificate chain matches the official certificate, accepting self-signed certificates outside the root, skipping intermediate certificate checks, and ignoring Basic Constraints or other important extensions.

• Detection Approach: Set up a device or emulator with proxy settings for Burp Suite, ZAP, or IronWASP. If traffic interception works and the application still functions normally, the implementation is flawed. Use SSLScan (original or rbsec fork) to identify endpoint-level implementation weaknesses.

• Platform-Specific Prevention:

  • iOS: Use the Secure Transport API via CFNetwork to designate trusted client certificates. Ensure NSURL calls do not allow self-signed or invalid certificates. Implement certificate pinning by exporting the certificate, bundling it with the app, and anchoring it to the trust object via connection:willSendRequestForAuthenticationChallenge:.
  • Android: Verify that AllowAllHostnameVerifier and SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER are not present in the codebase.

Actionable Takeaways

1. Disable all weak cipher suites and protocol versions (SSLv2, SSLv3) — enforce TLS 1.1+ at minimum and prefer TLS 1.2 for all mobile app communications.
2. Never allow connections using self-signed certificates in production apps, and always validate the complete certificate chain of trust.
3. Perform all sensitive communication over TLS — avoid mixing HTTP and HTTPS content, and ensure ad networks and analytics SDKs also use secure connections.
4. Implement certificate pinning as an additional layer of protection against MITM attacks, using platform-appropriate mechanisms (Secure Transport API on iOS, custom TrustManager on Android).
5. Test mobile app transport security by setting up an interception proxy — if the app functions normally through the proxy without certificate errors, the TLS implementation is insecure.
6. Add a second layer of encryption for highly sensitive data transmitted over TLS, and follow the OWASP Transport Layer Protection Cheat Sheet.