Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label Google Chrome HTTPS warning. Show all posts

Chrome Blocks Unauthorized Certificates After Three ccTLD Hijacks

 

Chrome has taken steps to protect users after attackers compromised three country-code top-level domains and exploited the incidents to acquire unauthorized HTTPS certificates for multiple organizations. The affected namespaces are .gh for Ghana, .sl for Sierra Leone and .as for American Samoa. Attackers targeted the third-party registries which own the ccTLDs rather than Google directly. 

In addition to the country-code top-level domain takeovers, the adversaries also modified the authoritative DNS records to compromise several Google domains and domains of other companies. Chrome reported that it is not evident that Certification Authorities (CAs) that issued the certificates acted in bad faith but instead concluded that the problem stemmed from attackers’ tampering with DNS infrastructure of the country-code domains. 

Chrome’s Secure Web and Networking Team responded to the incidents by utilizing CRLSets to block the unauthorized certificates associated with Google properties and coordinated with the CAs to revoke the certificates, protecting the users of the browsers and other clients. The list of impacted entities grew as Chrome analyzed Certificate Transparency (CT) logs and identified a number of large publicly traded companies and popular internet services. 

The team blocked certificates it suspected to be related to the attacks and reached out to the impacted businesses. Users of Chrome do not need to take any action as the protections are designed to be transparent and work in the background. However, Google warned that organizations should not rely on the browser to protect them against the attacks and that Chrome did not identify all the affected domains. Similarly, protections worked on Google Chrome and may have not triggered in other browsers and clients. 

Organizations are advised to ensure that they monitor the CT logs for all the domains and that they are notified if an unauthorized certificate is issued. This is critical because every certificate that is trusted by the public must be reported to CT logs. For domains that are impacted by the ongoing attacks, it is recommended to look over the most recent certificates to ensure that they have not been issued without authorization. Google recommended the use of restricted Certification Authority Authorization (CAA) records and the use of ACME account bindings when available. 

CAA records dictate which CAs can issue certificates and, while they do not prevent an attacker from using a hijacked domain to issue a certificate, they can help in ensuring that unknown CAs are not utilized. Additionally, the CAA records can prevent attackers from using domain-control validation for certificate issuance through misdirection. Using issuing restrictions and validation method restrictions can prevent attackers from using certificates’ domain validation through cached entries. These protections are only effective after the control of the domain is re-established. 

Chrome announced its intent to keep working on long-term projects to improve security and reduce the risks associated with the use of certificates. The proposed changes include shortening the lifespan of certificates and limiting the re-use of domain validation. They will continue to work to improve the Chrome Root Program with the Chrome Quantum-resistant Root Program as the Chrome ecosystem seeks to mitigate the risks posed by DNS and routing compromises.

Google Chrome Introduces Merkle Tree Certificates to Build Quantum-Resistant HTTPS

 

A fresh move inside Google Chrome targets long-term security of HTTPS links against risks tied to quantum machines. Instead of dropping standard X.509 certificates straight into the Chrome Root Store - ones using post-quantum methods - the team leans on an alternate design path. Speed stays high, system growth remains smooth, thanks to this structural twist shaping how protection rolls out online. 

The decision comes from Chrome’s Secure Web and Networking Team: conventional post-quantum X.509 certificates won’t enter the root program right now. Rather than adopt them outright, Google works alongside others on a different path - Merkle Tree Certificates (MTCs). Progress unfolds inside the PLANTS working group, shifting how HTTPS verification could function down the line. 

One way to look at MTCs, according to Cloudflare, is as an updated framework for how online trust systems operate today. Instead of relying on long chains of verification, these models aim to cut down excess - fewer keys, fewer signatures traded when devices connect securely. A key feature involves certification authorities signing just one root structure, known as a Tree Head, which stands in for vast groups of individual certificates. During a web visit, the user's browser gets a small cryptographic note confirming the site’s credentials live inside that larger authenticated structure. Rather than pulling multiple files across networks, only minimal evidence travels each time. 

One way this setup works is by fitting new quantum-resistant codes without needing much extra data flow. Large certificates often grow bulkier when using tougher encryption methods. Instead of linking security directly to file size, these compact certificates help maintain speed during secure browsing. With less information needed at connection start, performance stays high even under upgraded protection levels. 

Testing of MTCs is now happening, using actual internet data flows, alongside a step-by-step introduction schedule that runs until 2027. Right now, the opening stage focuses on checking viability through joint work with Cloudflare, observing how things run when exposed to active TLS environments. Instead of waiting, preparations are shifting ahead - by early 2027, those running Certificate Transparency logs, provided they had at least one accepted by Chrome prior to February 1, 2026, may join efforts to kickstart broader MTC availability. Moving forward, around late 2027, rules for admitting CAs into Google's new quantum-safe root store should be set, a system built only to handle MTC certificates. 

A shift like this one sits at the core of Google's approach to future-proofing online security. Rather than wait, the team is rebuilding trust systems so they handle both emerging risks and current efficiency needs. With updated certificates in place, stronger defenses can spread faster across services. Speed does not take a back seat - performance stays aligned with how people actually use browsers now.

Google Chrome to Show Stronger Warnings for Insecure HTTP Sites Starting October 2025

 

Google is taking another major step toward a safer web experience. Starting October 2025, Google Chrome will begin displaying clearer and more prominent warnings when users access public websites that do not use HTTPS encryption. The move is part of Google’s ongoing effort to make secure browsing the default for everyone.

At present, Chrome only displays a “Your connection is not private” message when a website’s HTTPS configuration is broken or misconfigured. However, this new update goes beyond that — it will alert users whenever they try to open any HTTP (non-HTTPS) website, emphasizing the risks of sharing personal data on unencrypted pages.

Google initially introduced optional warnings for insecure HTTP sites back in 2021, but users had to manually enable them. Over time, the adoption of HTTPS has skyrocketed — according to Google, between 95% and 99% of web traffic now takes place over secure HTTPS connections. This widespread adoption, the company says, “makes it possible to consider stronger mitigations against the remaining insecure HTTP.”

HTTPS, or Hypertext Transfer Protocol Secure, adds a layer of encryption that prevents malicious actors from intercepting or tampering with the information exchanged between users and websites. Without it, attackers can easily eavesdrop, inject malware, or steal sensitive data such as passwords and payment details.

In its official announcement, Google also highlighted that the largest contributor to insecure HTTP traffic comes from private websites — for example, internal business portals or personal web servers — as they often face challenges in obtaining HTTPS certificates. While these sites are “typically less dangerous than their public site counterparts,” Google cautions that HTTP navigation still poses potential risks.

Before the change applies to all users, Google plans to first roll it out to people who have Enhanced Safe Browsing enabled, starting in April 2026. This phased rollout will allow the company to monitor feedback and ensure a smooth transition. Chrome users will still retain control over their browsing experience — they can turn off these alerts by disabling the “Always Use Secure Connections” setting in the browser’s preferences.

This update reinforces Google’s long-term vision of making the internet fully encrypted and secure by default. With the vast majority of web traffic already protected, the company’s focus is now on phasing out the remaining insecure connections and encouraging all website owners to adopt HTTPS.