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.”
Cryptomator is an open source tool that transparently encrypts files that users upload to various cloud storage services, such as Dropbox or Google Drive.
With Cryptomator users set up what it calls vaults with encryption keys that only the user has access to (not the cloud provider). Files that are stored within these vaults are then encrypted automatically (including the filenames).
As long as the user has unlocked the vault on a local device, however, on that device the files are unencrypted automatically for the user. As Cryptomator puts it, this effectively creates a virtual hard drive that is encrypted and decrypted only with the user’s key.
Cryptomator encrypts file contents and names using AES. Your passphrase is protected against bruteforcing attempts using scrypt. Directory structures get obfuscated. The only thing which cannot be encrypted without breaking your cloud synchronization is the modification date of your files.
Cryptomator is a free and open source software licensed under the GPLv3. This allows anyone to check our code. It is impossible to introduce backdoors for third parties. Also we cannot hide vulnerabilities. And the best thing is: There is no need to trust us, as you can control us!
Along with free clients for Windows, Mac and Linxu, Cryptomator also has Android and iOS applications which they do charge for (the Android app is about $10).
SIGSALY was system for encrypting voice communications used during World War II,
SIGSALY used a random noise mask to encrypt voice conversations which had been encoded by a vocoder. The latter was used both to minimize the amount of redundancy (which is high in voice traffic), and also to reduce the amount of information to be encrypted. The voice encoding used the fact that speech varies fairly slowly as the components of the throat move. The system extracts information about the voice signal around 25 times a second.
. . .
Next, each signal was sampled for its amplitude once every 20 milliseconds. For the band amplitude signals, the amplitude converted into one of six amplitude levels, with values from 0 through 5. The amplitude levels were on a nonlinear scale, with the steps between levels wide at high amplitudes and narrower at low amplitudes. This scheme, known as “companding” or “compressing-expanding”, exploits the fact that the fidelity of voice signals is more sensitive to low amplitudes than to high amplitudes. The pitch signal, which required greater sensitivity, was encoded by a pair of six-level values (one coarse, and one fine), giving thirty-six levels in all.
A cryptographic key, consisting of a series of random values from the same set of six levels, was subtracted from each sampled voice amplitude value to encrypt them before transmission. The subtraction was performed using modular arithmetic: a “wraparound” fashion, meaning that if there was a negative result, it was added to six to give a positive result.
. . .
The SIGSALY terminal was massive, consisting of 40 racks of equipment. It weighed over 50 tons, and used about 30 kW of power, necessitating an air-conditioned room to hold it. Too big and cumbersome for general use, it was only used for the highest level of voice communications.
A dozen SIGSALY terminal installations were eventually set up all over the world. The first was installed in the Pentagon building rather than the White House, which had an extension line, as President Franklin Roosevelt knew of British Prime Minister Winston Churchill’s insistence that he be able to call at any time of the day or night. The second was installed 60 metres (200 ft) below street level in the basement of Selfridges department store on Oxford Street, London, close to the US Embassy on Grosvenor Square. The first conference took place on 15 July 1943, and it was used by both General Dwight D. Eisenhower as the commander of SHAEF, and Churchill, before extensions were installed to the Embassy, 10 Downing Street and the Cabinet War Rooms. One was installed in a ship and followed General Douglas MacArthur during his South Pacific campaigns. In total during WW2, the system supported about 3,000 high-level telephone conferences.
The installation and maintenance of all SIGSALY machines was undertaken by the specially formed and vetted members of the 805th Signal Service Company of the US Army Signal Corps. The system was cumbersome, but it worked very effectively. When the Allies invaded Germany, an investigative team discovered that the Germans had recorded significant amounts of traffic from the system, but had erroneously concluded that it was a complex telegraphic encoding system.
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.
As a sort of sequel to its highly successful HTTPS Everywhere campaign, the Electronic Frontier Foundation has initiated a STARTTLS Everywhere project to improve email security.
Unfortunately, this is likely to prove a bit more challenging than HTTPS Everywhere because of issues with STARTTLS,
Although many mailservers enable STARTTLS, most still do not validate certificates. Without certificate validation, an active attacker on the network can read and even modify emails sent through your supposedly “secure” connection. Since it’s not common practice to validate certificates, there’s often little incentive to present valid certificates in the first place. A brief experiment on Censys shows that about half of the mailservers that support STARTTLS use self-signed certificates.
. . .
When two mailservers support STARTTLS, their insecure connection is opportunistically upgraded to a secure one. In order to make that upgrade, the two mailservers ask each other if they support STARTTLS. Since this initial negotiation is unencrypted, network attackers can alter these messages to make it seem like neither server supports STARTTLS, causing any emails to be sent unencrypted. ISPs in the U.S. and abroad have been caught doing exactly this, and in 2014, several researchers found that encryption on outbound email from several countries were being regularly stripped.
But you have to start somewhere, and the EFF should be commended for going beyond simply issuing policy prescriptions and recommendations, and doing a lot of the heavy lifting to improve end user security.