Back in 2018, Google announced that beginning with Android 9, it would prevent apps from using unencrypted connections by default. As of December 2019, Google notes that 80 percent of all apps in the Google Play store use TLS, and that rises to 90 percent of all apps targeting Android 9 and higher.
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.
That last sentence is a bit concerning. If app developers want to explicitly make their apps communicate through unencrypted connections, that’s fine, but as far as I can tell there is no way that consumers are made aware of this.
Just as modern browsers warn me that the website I’m visiting doesn’t use encryption, Google should inform users when they are using apps that do so as well. I’d be happy with a notification on the Google Play store page for such apps that “This app sends network traffic over unencrypted channels” or something like that.
(Yes, users could set up a packet analysis tool to look at the data their phone is sending, but they shouldn’t have to do so).
NoSnoop is a Windows-based tool that will let users know if their SSL is being subjected to a man-in-the-middle attack.
NoSnoop is a standalone, browser-independent application that will perform SSL/TLS handshakes with a list of 250 popular websites and examine the certificate chains received from each server. It will alert on any unexpected certificates.
NoSnoop will check for obvious cases (such as interception by a local proxy, your employer’s SSL inspection gateways, or a malware infection), as well as more advanced attacks (for instance, if the root cert is valid but issued by an unexpected organization or country).
An entire scan typically takes less than 30 seconds.
This is currently in beta, so “bugs and/or false positives detections should be expected.”
Why the f— is ESPN still not using TLS in 2019? This is extremely irresponsible behavior from a company owned by one of the largest media companies in the world (Disney). There are zero excuses for putting its users at risk this way.
Mozilla’s Lin Clark has a cartoon guide to DNS over HTTPS that . . . well . . . bottom line, there is no way to talk about DNS over HTTPS without getting fairly technical (one of the subheads on Lin’s lengthy pice is “What isn’t fixed by TRR with DoH?”) but this is probably as close as anyone is going to get.
We are re-evaluating when we should start rejecting all SHA-1 SSL certificates (regardless of when they were issued). As we said before, the current plan is to make this change on January 1, 2017. However, in light of recent attacks on SHA-1, we are also considering the feasibility of having a cut-off date as early as July 1, 2016.
Concretely, we estimate the SHA-1 collision cost today (i.e., Fall 2015) between 75K$ and 120K$ renting Amazon EC2 cloud computing over a few months. By contrast, security expert Bruce Schneier previously projected (based on calculations from Jesse Walker) the SHA-1 collision cost to be ~173K$ by 2018. Note that he deems this to be within the resources of a criminal syndicate. Large corporations and governments may possess even greater resources and may not require Amazon EC2. Microsoft, Google and Mozilla have all announced that their respective browsers will stop accepting SHA-1 based SSL certificates by 2017 (and that SHA-1-based certificates should not be issued after 2015). In conclusion, our estimates imply SHA-1 collisions to be now (Fall 2015) within the resources of criminal syndicates, two years earlier than previously expected and one year before SHA-1 will be marked as unsafe in modern Internet browsers. This motivates our recommendations for industry standard SHA-1 to be retracted as soon as possible. With our new cost projections in mind, we strongly and urgently recommend against a recent proposal to extend the issuance of SHA-1 certificates with a year in the CAB/forum (discussion closes October 9 2015, vote closes October 16).