The client makes a connection to the server and the server responds with its SSL certificate. If that certificate was issued by a Certificate Authority that is trusted by the OS, then the connection is allowed. All data sent through this connection is then encrypted with the server’s public key. The part that is of interest to us is “trust.” For an attacker to perform a “man in the middle” attack, the mobile device would have to trust the attacker’s certificate. It is very unlikely that the attacker possesses a trusted certificate and therefore this is normally not an issue. However, SSL weaknesses have happened before and using SSL Pinning can mitigate this possibility.
It is also possible that the user herself is intentionally acting as the attacker in order to inspect the encrypted network traffic. The user may be using Charles or mitmproxy to manually install a trusted certificate. While perhaps having a perfectly legitimate reason to do this, the user might instead be trying to find an exploit in your web service.
Applications communicating over HTTPS and using SSL Pinning makes it non-trivial to perform Man-In-The-Middle attack and grab the network traffic in clear text using the proxy tools. For further reading about SSL Pinning, I would recommend OWASP article to get started with.
So What Is SSL Pinning?
SSL Pinning is making sure the client checks the server’s certificate against a known copy of that certificate. Simply bundle your server’s SSL certificate inside your application, and make sure any SSL request first validates that the server’s certificate exactly matches the bundle’s certificate.