148 captures
10 Jun 2017 - 11 Jul 2026
Oct
NOV
Dec
29
2020
2021
2022
success
fail
About this capture
COLLECTED BY
Collection:
Common Crawl
Web crawl data from Common Crawl.
TIMESTAMPS
The Wayback Machine - https://web.archive.org/web/20211129121737/https://security.googleblog.com/2013/12/
Security Blog
The latest news and insights from Google on security and safety on the Internet
Further improving digital certificate security
December 7, 2013
Posted by Adam Langley, Security Engineer
Late on December 3rd, we became aware of unauthorized digital certificates for several Google domains. We investigated immediately and found the certificate was issued by an
intermediate certificate authority
(CA) linking back to ANSSI, a French certificate authority. Intermediate CA certificates carry the full authority of the CA, so anyone who has one can use it to create a certificate for any website they wish to impersonate.
In response, we updated Chrome’s certificate revocation metadata immediately to block that intermediate CA, and then alerted ANSSI and other browser vendors. Our actions addressed the immediate problem for our users.
ANSSI has found that the intermediate CA certificate was used in a commercial device, on a private network, to inspect encrypted traffic with the knowledge of the users on that network. This was a violation of their procedures and they have asked for the certificate in question to be revoked by browsers. We updated Chrome’s revocation metadata again to implement this.
This incident represents a serious breach and demonstrates why
Certificate Transparency
, which we developed in 2011 and have been advocating for since, is so critical.
Since our priority is the security and privacy of our users, we are carefully considering what additional actions may be necessary.
[Update
December 12: We have decided that the ANSSI certificate authority will be limited to the following top-level domains in a future version of Chrome:
.fr
.gp (Guadeloupe)
.gf (Guyane)
.mq (Martinique)
.re (Réunion)
.yt (Mayotte)
.pm (Saint-Pierre et Miquelon)
.bl (Saint Barthélemy)
.mf (Saint Martin)
.wf (Wallis et Futuna)
.pf (Polynésie française)
.nc (Nouvelle Calédonie)
.tf (Terres australes et antarctiques françaises)]
Internet-wide efforts to fight email phishing are working
December 6, 2013
Posted by Elie Bursztein, anti-abuse research lead and Vijay Eranti, Gmail anti-abuse technical lead
Editor's Note:
This post was updated on February 9th, 2016. Adoption numbers reflect state of authentication as of this date.
Since 2004, industry groups and standards bodies have been working on developing and deploying email authentication standards to prevent email impersonation. At its core, email authentication standardizes how an email’s sending and receiving domains can exchange information to authenticate that the email came from the rightful sender.
Now, nearly a decade later, adoption of these standards is widespread across the industry, dramatically reducing spammers’ ability to impersonate domains that users trust, and making email phishing less effective. 97.4% of non-spam emails sent to Gmail users come from authenticated senders as of 2016, a sharp increase from 2013 when only 91.4% of the emails were authenticated. Authentication helps Gmail prevent billions of impersonating email messages a year landing in users’ inboxes.
More specifically, the 97.4% of the authenticated non-spam emails sent to Gmail users come from senders that have adopted one or more of the following email authentication standards: DKIM (DomainKey Identified Email) or SPF (Sender Policy Framework).
Here are some statistics that illustrate the scale of what we’re seeing:
86.8% of the emails we received are signed according to the (DKIM) standard (up from 76.9% in 2013). Over two million domains (weekly active) have adopted this standard (up from 0.5 millions 2013).
95.3% of incoming emails we receive come from SMTP servers that are authenticated using the SPF standard (up from 89.1% in 2013). Over 7.8 million domains (weekly active) have adopted the SPF standard (up from 3.5 million domains in 2013).
85% of incoming emails we receive are protected by both the DKIM and SPF standards (up from 74.7% in 2013).
Over 162,000 domains have deployed domain-wide policies that allow us to reject hundreds of millions of unauthenticated emails every week via the DMARC standard (up from 80,000 in 2013).
Join the fight against email spam
As more domains implement authentication, phishers are forced to target domains that are not yet protected. If you own a domain that sends email, the most effective action you can take to help us and prevent spammers from impersonating your domain is to set up DKIM, SPF and DMARC. Check our help pages on
DKIM
,
SPF
,
DMARC
to get started.
When using DKIM, please make sure that your public key is at least 1024 bits, so that attackers can’t crack it and impersonate your domain. The use of weak cryptographic keys -- ones that are 512 bits or less -- is one of the major sources of DKIM configuration errors (21%).
If you own domains that are never used to send email, you can still help prevent abuse. All you need to do is create a DMARC policy that describes your domain as a non-sender. Adding a “reject” policy for these domains ensures that no emails impersonating you will ever reach Gmail users’ inboxes.
While the fight against spammers is far from over, it’s nevertheless encouraging to see that community efforts are paying off. Gmail has been an early adopter of these standards and we remain a strong advocate of email authentication. We hope that publishing these results will inspire more domain owners to adopt the standards that protect them from impersonation and help keep email inboxes safe and clean.
Labels
#sharethemicincyber
#supplychain #security #opensource
android
android security
android tr
app security
big data
biometrics
blackhat
C++
chrome
chrome security
CTF
diversity
encryption
federated learning
fuzzing
Gboard
google play
google play protect
interoperability
kubernetes
linux kernel
memory safety
Open Source
pha family highlights
pixel
privacy
private compute core
Rowhammer
rust
Security
sigstore
spyware
supply chain
targeted spyware
tensor
Titan M2
vulnerabilities
Archive
2021
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Aug
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
2010
Nov
Oct
Sep
Aug
Jul
May
Apr
Mar
2009
Nov
Oct
Aug
Jul
Jun
Mar
2008
Dec
Nov
Oct
Aug
Jul
May
Feb
2007
Nov
Oct
Sep
Jul
Jun
May
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.
Follow