Android : Unsafe custom SSL implementation (non-trivial)

The class that implements the X509TrustManager or SSLSocketFactory interface can contain trivial methods. This can lead to a loss of confidentiality of the data transferred via SSL / TSL protocol.

Within the establishing of a protected connection (handshake) server sends its public key and certificate, which are a cryptographic proof that the public key belongs to the owner of the server, to the client. The authenticity of certificates is provided by Certification Authority.

If it is necessary for the application functioning to take the certificate that is not signed by a recognized certification authority (for example, a self-signed certificate), then developers create a class that implements the X509TrustManager or SSLSocketFactory interface. Often methods of this class are trivial (accepting all certificates), which makes the application vulnerable to man in the middle (MitM) attacks. By providing a valid self-signed certificate an attacker can violate the confidentiality of the connection and get an access to valuable data.

Even if the methods of the redefined class are not trivial, their implementation is likely to be contain mistakes leading to the same consequences.

A possible attack scenario:

1. The attacker enters the user’s WLAN and redirects user’s traffic through the attacker’s server (for example, via DNS cache poisoning).
2. The user initiates a connection to https://safeserver.example.com.via an SSL / TLS protocol through the application.
3. The attacker sends his/her own public key and a self-signed certificate generated by him/herself for the https://safeserver.example.com.domain to the application .
4. The application verifies that the received certificate matches the requested domain, ignoring the fact that the received certificate is self-signed.

Insufficient Transport Layer Protection vulnerabilities take the third place in the “OWASP Mobile Top 2014” mobile platforms vulnerabilities ranking.