15

We're using okhttp in our Android project to talk to our API; all communications are encrypted with SSL/TLS, and our servers can speak SPDY. We're also linking in Google Play Services for the fused location provider and some other functionality.

Part of Play Services which we're not currently using is their security provider, which promises to upgrade the device's SSL stack to somehow protect against various vulnerabilities. However, the docs are somewhat vague as to what the provider actually does and as to what SSL methods are affected by it and which are not (a few examples of each are provided, but not a comprehensive list).

So, I guess my question is twofold:

  • Will the dynamic security provider even work with okhttp, or does okhttp rely on lower-level (or higher-level) APIs that are not affected by installing the provider?

  • Assuming it does work, what are the benefits? Are there security benefits worth caring about? Will it in fact fix the ALPN-related native crash in okhttp 2.2, as nfuller hints it might?

Community
  • 1
  • 1
mlc
  • 1,668
  • 2
  • 16
  • 30

1 Answers1

11

TL;DR: Yes.

The Play Services Dynamic Security Provider is a JCA Cryptographic Service Provider (CSP). A Java program can have multiple CSP registered and each CSP can provide differing implementations of security primitives like hashing algorithms. Here's a the list of CSP included in Android 2.3:

  • AndroidOpenSSL version 1.0
  • DRLCertFactory version 1.0
  • BC version 1.45
  • Crypto version 1.0
  • HarmonyJSSE version 1.0

When you activate the Play Services Dynamic Security Provider as outlined in the Android Developer Documentation, just another provider is added to the top of the list:

  • GmsCore_OpenSSL version 1.0
  • AndroidOpenSSL version 1.0
  • DRLCertFactory version 1.0
  • BC version 1.45
  • Crypto version 1.0
  • HarmonyJSSE version 1.0

When OkHttp (or any other part of your application) "does security" using JCA it selects a provider according to it capabilities and the preference (sort order) which means that GmsCore_OpenSSL will be used.

By relying on GmsCore_OpenSSL instead of whatever is bundled with the device your app is running on you get an up-to-date implementation of the provided security primitives even on ancient devices with Android 2.3, i.e. no more SSLv3, TLS 1.2 (Android 2.3 doesn't even support TLS 1.1) with current cipher-suites and patched security holes. Because the Play Services are updated independently of Android the Play Services Dynamic Security Provider stays current and hence it makes sense to use it on current devices too.

If you want to target devices that do not have access to the Play Services or you do not like to use the Play Services, you can include conscrypt in your application. OkHttp supports it since version 3.10. But then you've to regularly update your app.

aha
  • 3,702
  • 3
  • 38
  • 47
  • Official [page](https://developer.android.com/training/articles/security-gms-provider): **_Caution: Updating a device's security Provider does not update android.net.SSLCertificateSocketFactory. Rather than using this class, we encourage app developers to use high-level methods for interacting with cryptography. Most apps can use APIs like HttpsURLConnection without needing to set a custom TrustManager or create an SSLCertificateSocketFactory._** Given this caution, how can I use Google Play Services Security provider with custom TrustManager: e.g: certificate pinning, untrusted CA? – garnet Jul 03 '18 at 08:40
  • @garnet I assume that you'll rather get helpful answer if you post it as a separate question. – aha Jul 05 '18 at 06:57
  • @aha can you check this ? https://stackoverflow.com/questions/73695027/google-suggested-security-providerinstaller-downgrade-tls-to-1-2 – Alessandro Scarozza Sep 15 '22 at 12:34