General information
There is no out of the box solution from Google to use stronger encryption for the communication between your Android client and a server.
Google provides some information on how to use SSL on the Android developer website titled “Security with HTTPS and SSL“. This site contains two warnings you should not forget.
- Do not use a TrustManager that does nothing.
- Replacing the HostnameVerifier can be very dangerous.
A reason to use a TrustManager that does nothing could be for local or Alpha testing where you don’t have a valid SSL certificate on the server. Another could be to give QA the option to debug network traffic. If for some reason you do use a TrustManager that does nothing, make sure this implementation can never make it to a production version of the application. One way to do that is only include the empty TrustManager in one of the (testing) application flavors.
If you do want to use a custom HostnameVerifier, use composition to reuse the system’s default HostnameVerifier. This way you can add your own verification and still benefit from the default verification. You should apply the same when building your own TrustManager, that way your validation is never worse than the default system validation.
Pinning certificates
One way to make the encryption stronger is by using pinned certificates. This will help your application protect itself from fraudulently issued certificates. I will explore two ways of pinning a certificate. One is including the actual certificate, the other is to use SPKI or Subject Public Key Info.
Getting the server certificate
Before getting started with either method for pinning a certificate, you need to get hold of the server certificate. The easiest way to optain that would be to ask your system administrator. If that is not possible, you could use OpenSSL or FireFox to just save it from the browser. For more details, see “How to save a remote server SSL certificate locally as a file” on SuperUser.com.
Including the certificate
Start by including the certificate file (as raw resource) in your APK.
After this, implement your own TrustManager that uses the following pseudo-code to analyse the received certificate.
Get the key from the bundled certificate.
- FileInputStream fis = new FileInputStream("path_to_pem");
- CertificateFactory cf = CertificateFactory.getInstance("X.509");
- java.security.cert.Certificate c = cf.generateCertificate(fis);
- System.out.println(c.toString());
- // will get you the public key object you can compare against.
- RSAPublicKey pk = (RSAPublicKey) c.getPublicKey();
- System.out.println(pk.toString());
- String s = new BigInteger(1, pk.getEncoded()).toString(16);
- System.out.println(s);
Get the server key.
- // that gets the public key provided by the server out of the chain.
- RSAPublicKey pubkey = (RSAPublicKey) chain[0].getPublicKey();
Compare the two keys.
- // Where pk is the one loaded from your app file space.
- pubkey.equals(pk);
SPKI
An alternative approach to bundling the certificate with your application is to use the Subject Public Key Info method. This will just store the certificate’s fingerprint instead of a whole file.
To generate the fingerprint for your certificate, follow the instructions in “Appendix A” of the “Public Key Pinning Extension for HTTP” document, example:
- openssl x509 -noout -in certificate.pem -pubkey | \
- openssl asn1parse -noout -inform pem -out public.key
- openssl dgst -sha256 -binary public.key | openssl enc -base64
You can calculate the same fingerprint in Java using the snippet below:
- // Assume the 'certificate' is a X509Certificate.
- MessageDigest digest = MessageDigest.getInstance("SHA-256");
- byte[] encodedKey = certificate.getPublicKey().getEncoded();
- byte[] hash = digest.digest(encodedKey);
- String fingerprint = Base64.encodeToString(hash, Base64.NO_WRAP);
Notes
SSL certificates can be invalidated for various reasons (they expire, get compromised, etc). Because of this you should consider showing a message to the user when pinning a certificate fails.
To avoid your app breaking when a certificate gets invalidated, you can keep a list of valid public keys. Start with the first in the list, if that doesn’t work fall back to the next public key in the list.
Update or change a certificate before the previous one expires. Unless the certificate is compromised, the public key will most likely stay the same. (If you use the same private key/CSR.)