Security Blog
The latest news and insights from Google on security and safety on the Internet
Sustaining Digital Certificate Security
2015 m. spalio 28 d.
Posted by Ryan Sleevi, Software Engineer
This post updates our
previous notification
of a misissued certificate for google.com
Following our notification, Symantec published
a report
in response to our inquiries and disclosed that 23 test certificates had been issued without the domain owner’s knowledge covering five organizations, including Google and Opera.
However, we were still able to find several more questionable certificates using only the Certificate Transparency logs and a few minutes of work. We shared these results with other root store operators on October 6th, to allow them to independently assess and verify our research.
Symantec performed another audit and, on October 12th, announced that they had found an additional
164 certificates
over 76 domains and
2,458 certificates
issued for domains that were never registered.
It’s obviously concerning that a CA would have such a long-running issue and that they would be unable to assess its scope after being alerted to it and conducting an audit. Therefore we are firstly going to require that as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency. In this case, logging of non-EV certificates would have provided significantly greater insight into the problem and may have allowed the problem to be detected sooner.
After this date, certificates newly issued by Symantec that do not conform to the Chromium Certificate Transparency policy may result in interstitials or other problems when used in Google products.
More immediately, we are requesting of Symantec that they further update their public incident report with:
A post-mortem analysis that details why they did not detect the additional certificates that we found.
Details of each of the failures to uphold the relevant Baseline Requirements and EV Guidelines and what they believe the individual root cause was for each failure.
We are also requesting that Symantec provide us with a detailed set of steps they will take to correct and prevent each of the identified failures, as well as a timeline for when they expect to complete such work. Symantec may consider this latter information to be confidential and so we are not requesting that this be made public.
Following the implementation of these corrective steps, we expect Symantec to undergo a Point-in-time Readiness Assessment and a third-party security audit. The point-in-time assessment will establish Symantec’s conformance to each of these standards:
WebTrust Principles and Criteria for Certification Authorities
WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security
WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL
The third-party security audit must assess:
The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool.
That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key.
That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS.
We may take further action as additional information becomes available to us.
Behind the red warning: more info about online site safety
2015 m. spalio 20 d.
Posted by
Adrienne Porter Felt, Chrome Security Engineer and Warning Wizard
Emily Schechter, Safe Browsing Program Manager and Menace to Malware
Ke Wang, Safe Browsing Engineer and Developer of Defense
You’re browsing the web, checking out the latest news on your favorite band, when suddenly you see a red warning screen: “The site ahead contains malware.” These warnings aren’t new—since 2006, Google Safe Browsing has shown them when you navigate to an unsafe site. The warnings protect you from harms caused by unsafe sites, such as malware infections and phishing attacks. But it hasn’t always been clear why a specific website triggers a warning, and you may want to learn more.
To demystify these warnings, we’re launching a
Site Status section
in the Transparency Report. The next time you come across a Safe Browsing warning, you can search for the blocked website in the Transparency Report to learn why it’s been flagged by our systems.
The new Site Status section of the Transparency Report replaces our previous
Safe Browsing diagnostic page
. It includes a clearer interface and simpler explanations of the issues, such as details for sites that host
unwanted software
. We’ve added it to the Transparency Report so that the Safe Browsing section of the report is a one-stop shop for information to help you understand what Safe Browsing is and how it works.
If a favorite website shows up as “dangerous,” it’s often due to user-uploaded bad content or a temporary malware infection. The Site Status will return to normal once the webmaster has cleaned up the website. To help speed up this process, we automatically give the webmaster a heads-up about the problem via
Search Console
; if you use
Google Analytics
, we’ll also warn you there if your site has malware on it. (Webmasters, check the
help center
to learn how to remove malware from your websites.)
We’re constantly working to keep users safe and informed online. Visit the updated Site Status section in the
Transparency Report
to experience it yourself.
Simplifying the Page Security Icon in Chrome
2015 m. spalio 13 d.
Posted by Lucas Garron and Chris Palmer, Chrome security team
Sometimes, websites try to use HTTPS to be secure and get it mostly right, but they have minor errors. Until recently, Chrome marked this security state with a yellow “caution triangle” badge on the page security icon in the URL bar.
Starting with version 46, Chrome will mark the “HTTPS with Minor Errors” state using the same neutral page icon as HTTP pages.
There are two reasons for this:
This change is a better visual indication of the security state of the page relative to HTTP.
Chrome users will have fewer security states to learn.
(Not) Warning About Mixed Content
This change will mainly affect HTTPS pages that contain certain
mixed content
, such as HTTP images.
Site operators face a dilemma: Switching an HTTP site to HTTPS can initially result in mixed content, which is undesirable in the long term but important for debugging the migration. During this process the site may not be fully secured, but it will usually not be less secure than before.
Removing the yellow “caution triangle” badge means that most users will not perceive a warning on mixed content pages during such a migration. We hope that this will encourage site operators to switch to HTTPS sooner rather than later.
Fewer Security States
This change will reduce the number of page security states in Chrome from four to three.
We have to strike a balance: representing the security state of a webpage as accurately as possible, while making sure users are not overwhelmed with too many possible states and details. We’ve come to understand that our yellow “caution triangle” badge can be confusing when compared to the HTTP page icon, and we believe that it is better not to emphasize the difference in security between these two states to most users. For developers and other interested users, it will still be possible to tell the difference by checking whether the URL begins with “https://”.
In the long term, we hope that most sites on the internet will become secure, and we
plan
to reduce the icon to just two states: secure and not secure. The change announced in this post is a small step in that direction.
Etiketės
#sharethemicincyber
#supplychain #security #opensource
AI Security
android
android security
android tr
app security
big data
biometrics
blackhat
C++
chrome
chrome enterprise
chrome security
connected devices
CTF
diversity
encryption
federated learning
fuzzing
Gboard
google play
google play protect
hacking
interoperability
iot security
kubernetes
linux kernel
memory safety
Open Source
pha family highlights
pixel
privacy
private compute core
Rowhammer
rust
Security
security rewards program
sigstore
spyware
supply chain
targeted spyware
tensor
Titan M2
VDP
vulnerabilities
workshop
Archive
2026
bal.
kov.
vas.
saus.
2025
gruod.
lapkr.
spal.
rugs.
rugp.
liep.
birž.
geg.
bal.
kov.
vas.
saus.
2024
gruod.
lapkr.
spal.
rugs.
rugp.
liep.
birž.
geg.
bal.
kov.
vas.
saus.
2023
gruod.
lapkr.
spal.
rugs.
rugp.
liep.
birž.
geg.
bal.
kov.
vas.
saus.
2022
gruod.
lapkr.
spal.
rugs.
rugp.
liep.
birž.
geg.
bal.
kov.
vas.
saus.
2021
gruod.
lapkr.
spal.
rugs.
rugp.
liep.
birž.
geg.
bal.
kov.
vas.
saus.
2020
gruod.
lapkr.
spal.
rugs.
rugp.
liep.
birž.
geg.
bal.
kov.
vas.
saus.
2019
gruod.
lapkr.
spal.
rugs.
rugp.
liep.
birž.
geg.
bal.
kov.
vas.
saus.
2018
gruod.
lapkr.
spal.
rugs.
rugp.
liep.
birž.
geg.
bal.
kov.
vas.
saus.
2017
gruod.
lapkr.
spal.
rugs.
liep.
birž.
geg.
bal.
kov.
vas.
saus.
2016
gruod.
lapkr.
spal.
rugs.
rugp.
liep.
birž.
geg.
bal.
kov.
vas.
saus.
2015
gruod.
lapkr.
spal.
rugs.
rugp.
liep.
birž.
geg.
bal.
kov.
vas.
saus.
2014
gruod.
lapkr.
spal.
rugs.
rugp.
liep.
birž.
bal.
kov.
vas.
saus.
2013
gruod.
lapkr.
spal.
rugp.
birž.
geg.
bal.
kov.
vas.
saus.
2012
gruod.
rugs.
rugp.
birž.
geg.
bal.
kov.
vas.
saus.
2011
gruod.
lapkr.
spal.
rugs.
rugp.
liep.
birž.
geg.
bal.
kov.
vas.
2010
lapkr.
spal.
rugs.
rugp.
liep.
geg.
bal.
kov.
2009
lapkr.
spal.
rugp.
liep.
birž.
kov.
2008
gruod.
lapkr.
spal.
rugp.
liep.
geg.
vas.
2007
lapkr.
spal.
rugs.
liep.
birž.
geg.
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.
Follow