Loading story…
Google is adding platform-level TLS Encrypted Client Hello (ECH) support in Android 17, enabling compatible apps targeting the release to encrypt hostname metadata—including Server Name Indication (SNI)—during TLS handshakes. Used alongside Private DNS, ECH reduces ISPs’, Wi-Fi operators’, and other passive observers’ ability to identify websites and services users access; ECH GREASE will also generate cover traffic when a destination does not support ECH.
The implementation follows RFC 9849, which standardizes ECH’s encryption of an inner ClientHello under a server public key and specifies anti-downgrade, retry, and denial-of-service safeguards. Android 17 will additionally require permission for app local-network discovery and connections, enable Certificate Transparency by default, and allow participating carriers to disable 2G automatically to reduce exposure to rogue base stations and SMS blasters.
See the reporting duties and controls this puts on the clock.
4 events from the most recent confirmed update back to the earliest known activity.
OkHttp released opt-in Encrypted Client Hello support, allowing compatible Android 17/API 37 TLS stacks to encrypt the requested domain name during TLS connections. The release added HTTPS DNS resource-record retrieval for ECH and warned that AndroidDns lookups are unencrypted by default.
Google announced mandatory verification requirements for Android application developers, under which verified developers can distribute apps through Google Play and alternative channels. The company said rollout is scheduled to begin in September 2027.
Google announced Android 17 platform support for ECH, enabled by default for Android-17-targeting apps using compatible networking libraries. The announced protections also include local-network access permissions, Certificate Transparency by default, and optional carrier-led automatic 2G disablement.
The IETF published RFC 9849 as a Standards Track specification for TLS Encrypted Client Hello (ECH), defining encryption of ClientHello metadata such as SNI and ALPN using HPKE.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See what this changes for your reporting obligations and which controls it puts on the clock.
18 references tracked. Mallory keeps watching after this page renders.
malware.news
Open sourcezdnet.fr
Open sourcezdnet.com
Open sourcexakep.ru
Open sourcegithub.com
Open sourcerfc-editor.org
Open sourcecertificate.transparency.dev
Open sourcedatatracker.ietf.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Apple released an *iOS/iPadOS 26.4 developer beta* that adds **end-to-end encryption (E2EE) for RCS messaging** in limited testing, with availability constrained by device/carrier support and currently limited to **Apple-to-Apple** RCS conversations. The implementation is tied to upgrading to **RCS Universal Profile 3.0** built on the **Messaging Layer Security (MLS)** protocol, aligning with the GSMA’s prior move to standardize E2EE for RCS. The beta also expands platform hardening by allowing apps to opt into the full protections of **Memory Integrity Enforcement (MIE)** (beyond the previously available “Soft Mode”), and reporting indicates Apple may enable **Stolen Device Protection** by default in this release line. Google released the first *Android 17 beta* with multiple privacy/security changes aimed at tightening network and cryptographic defaults and improving user control. Android 17 **deprecates** the `android:usesCleartextTraffic` manifest attribute; apps targeting Android 17+ that set `usesCleartextTraffic="true"` without a **Network Security Configuration** will have cleartext traffic blocked by default, pushing developers toward more granular policy via configuration files. The beta also introduces a public **HPKE (Hybrid Public Key Encryption)** Service Provider Interface, adds user preference controls for **VoIP call history integration**, and expands **Wi‑Fi ranging** for proximity detection and secure peer-to-peer discovery.
Jun 29, 2026
Google has released **Android 17**, publishing the source code to AOSP under the tag `android-17.0.0_r1` and beginning rollout to supported Pixel devices, with broader availability planned across OEMs including HONOR, Lenovo, OnePlus, OPPO, vivo, Xiaomi, and others. Google also made **Generic System Images** available for `ARM64` and `x86_64`, while the platform adds major usability and device features such as foldable enhancements, App Bubbles, Handoff support, VVC/H.266 video, RAW14, HE-AAC, BLE hearing-aid improvements, and OpenJDK 25 integration. The release introduces a broad set of security and privacy changes, including tighter controls for **contacts**, **location**, and **local network** access, expanded one-time-password handling beyond SMS, stricter restrictions on **dynamic code loading**, stronger lost-device protections, improved threat detection, enhanced **Advanced Protection**, and stricter PIN retry limits. Google also added Certificate Transparency-related enhancements, support for **HPKE** cryptography and **ML-DSA** APK signatures, and continued restrictions on cleartext traffic, alongside Pixel-specific updates delivered through the June Pixel Drop.
Jul 12, 2026
Google said **Android 17** will begin a broad migration to post-quantum cryptography as part of a plan to harden the platform against future quantum attacks on public-key systems. The company is introducing quantum-resistant protections across core trust components, including **Android Verified Boot**, **Remote Attestation**, **KeyMint**, and **Android Keystore**, with support centered on the NIST-standardized `ML-DSA` algorithm. Google said the move is intended to build a quantum-resistant chain of trust spanning device boot, identity verification, and hardware-backed security services. Google also said **Google Play** will support hybrid app signing that combines classical and post-quantum signatures, and will begin generating quantum-safe `ML-DSA` signing keys for new apps while allowing existing apps to opt in. The company is targeting completion of its broader post-quantum migration by **2029**, citing the risk of **store-now-decrypt-later** attacks and warning that organizations should begin adopting NIST-developed PQC standards before fault-tolerant quantum computers can break current encryption. Google added that future Play updates are expected to support hybrid key upgrades and prompt developers to rotate signing keys every two years.
Jun 29, 2026