Skip to main content
banner image
venafi logo

Android Implements TLS Encryption by Default

Android Implements TLS Encryption by Default

side image of a hand being held out to signal "stop"
December 31, 2019 | Guest Blogger: Kim Crawley


Ideally, as much of your internet traffic as possible should be routed through TLS encryption. You don’t want a cyber attacker to perform a man-in-the-middle attack on your Android device as you use the internet! Some people do online banking on their phones. Others buy things from Amazon and other online retailers, with their Android device as their endpoint. People often have NFC based payment apps on their phone, like Google Pay or Samsung Pay. Those are connected to your bank account, and they often must communicate with the internet.



"Not All TLS Sessions Are Equally Secure"

Your Android phone also often transmits credentials, including passwords, to your various online services. And when data packets from your phone don’t contain sensitive information, the packet headers still contain information that can be used to exploit your Android device or the servers you’re communicating with. So yeah, as much TLS encryption as possible is ideal. But not all TLS sessions are equally secure, there are various factors to consider when it comes to protecting mobile machine identities.

 

 


Due to the cybersecurity importance of encrypting your internet traffic, a recent post on Google’s Security Blog makes me optimistic.


Google’s Bram Bonné and Chad Brubaker wrote:
 

“Android 7 (API level 24) introduced the Network Security Configuration in 2016, allowing app developers to configure the network security policy for their app through a declarative configuration file. To ensure apps are safe, apps targeting Android 9 (API level 28) or higher automatically have a policy set by default that prevents unencrypted traffic for every domain.
 

Today, we’re happy to announce that 80% of Android apps are encrypting traffic by default. The percentage is even greater for apps targeting Android 9 and higher, with 90% of them encrypting traffic by default.
 

Since November 1, 2019, all app (updates as well as all new apps on Google Play) must target at least Android 9. As a result, we expect these numbers to continue improving. Network traffic from these apps is secure by default and any use of unencrypted connections is the result of an explicit choice by the developer.”



 

Good job, Google! My phone runs Android 9, so honestly, I breathed a sigh of relief.
 

What Google is Doing

Ultimately, it’s the responsibility of app developers to help implement TLS into their software. As Google’s blog post continues:
 

“For apps targeting Android 9 and higher, the out-of-the-box default is to encrypt all network traffic in transit and trust only certificates issued by an authority in the standard Android CA set without requiring any extra configuration. Apps can provide an exception to this only by including a separate Network Security Config file with carefully selected exceptions.
 

If your app needs to allow traffic to certain domains, it can do so by including a Network Security Config file that only includes these exceptions to the default secure policy. Keep in mind that you should be cautious about the data received over insecure connections as it could have been tampered with in transit.”
 

It’s my understanding that Google isn’t a certificate authority (CA), but they have a default Android CA set, which is probably easier for developers to use. The default Android CA set was established in 2016. As Google’s Chad Brubaker wrote at the time:
 

“In Android Nougat, we’ve changed how Android handles trusted certificate authorities (CAs) to provide safer defaults for secure app traffic. Most apps and users should not be affected by these changes or need to take any action. The changes include:
 

  • Safe and easy APIs to trust custom CAs.
  • Apps that target API Level 24 and above no longer trust user- or admin-added CAs for secure connections, by default.
  • All devices running Android Nougat offer the same standardized set of system CAs—no device-specific customizations.”
     

Or, Use Your Own CA

There are also options for developers to use their own CAs, if they really want to do the extra work:
 

“Protection of all application data is a key goal of the Android application sandbox. Android Nougat changes how applications interact with user- and admin-supplied CAs. By default, apps that target API level 24 will—by design—not honor such CAs unless the app explicitly opts in. This safe-by-default setting reduces application attack surface and encourages consistent handling of network and file-based application data...
 

Customizing the CAs your app trusts on Android Nougat is easy using the Network Security Config. Trust can be specified across the whole app or only for connections to certain domains, as needed. Below are some examples for trusting a custom or user-added CA, in addition to the system CAs. For more examples and details, see the full documentation.”
 

I figure that unless the app developer has a specific information security policy which requires the use of a specific CA, they’ll probably just default to the Android CA set. That’s perfectly understandable, we all have so much work and so many responsibilities on our plate that using a default is tempting, as long as we trust it.
 

"a CA with poor cybersecurity can render TLS encryption nearly pointless"
 

But CAs are supposed to assure the authenticity and integrity of the machine identities that are used in a TLS session. Hence, a CA with poor cybersecurity or significant vulnerabilities can render TLS encryption nearly pointless.


Anastasios Arampatzis recently wrote here on Venafi’s blog about overall PKI (public key infrastructure) security. He examined a research report about PKI, and noted how choosing the right or wrong CA can make all the difference:
 

“CAs can ‘present a risk to the entire network,’ as the researchers note, but organizations can do a lot to eliminate this single point of failure. They should establish a formal certificate management program with executive leadership, guidance, and support. This program should include clearly defined policies, processes, and roles and responsibilities for the certificate owners and the Certificate Services team, as well as a central Certificate Service.



 

A central Certificate Service

includes technology-based solutions that provide automation and that support certificate owners in effectively managing their certificates. This service should include the technology/services for CAs, certificate discovery, inventory management, reporting, monitoring, enrollment, installation, renewal, revocation, and other certificate management operations. The central Certificate Service should also provide self-service access for certificate owners to be able to configure and operate the services for their areas without requiring significant interaction with the Certificate Services team.”
 

So, let this be a warning to Android app developers. Google’s move to make sure as many Android apps as possible use TLS wherever it’s applicable will probably improve the security of people’s Android devices. But how developers implement TLS and its associated PKIs and CAs is the most important factor. For TLS to provide effective encryption, your PKIs and choice of CAs is absolutely crucial. Proceed with caution, and if you do, then Google’s recent move will be beneficial to users and developers alike.
 

Related posts

 

Like this blog? We think you will love this.
a young businessman pulling at his hair, exasperated
Featured Blog

The Dangers of Key Reuse

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

CIO Study: Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection
Industry Research

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection

Machine Identity Protection for Dummies
eBook

Machine Identity Protection for Dummies

About the author

Guest Blogger: Kim Crawley
Guest Blogger: Kim Crawley

Kim Crawley writes about all areas of cybersecurity, with a particular interest in malware and social engineering. In addition to Venafi, she also contributes to Tripwire, AlienVault, and Cylance’s blogs. She has previously worked for Sophos and Infosecurity Magazine.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat