148 captures
08 Jan 2018 - 11 Jul 2026
Apr
MAY
Jun
23
2021
2022
2023
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/20220523024011/https://security.googleblog.com/2017/09/
Security Blog
The latest news and insights from Google on security and safety on the Internet
Broadening HSTS to secure more of the Web
September 27, 2017
Posted by Ben McIlwain, Google Registry
The security of the Web is of the utmost importance to Google. One of the most powerful tools in the Web security toolbox is ensuring that
connections to websites are encrypted using HTTPS
, which prevents Web traffic from being intercepted, altered, or misdirected in transit. We have taken many actions to make the use of HTTPS more widespread, both within Google and on the larger Internet.
We began in 2010 by
defaulting to HTTPS for Gmail
and starting the transition to encrypted search by default. In 2014, we started encouraging other websites to use HTTPS by
giving secure sites a ranking boost in Google Search
. In 2016, we became a platinum sponsor of
Let’s Encrypt
, a service that provides simple and free SSL certificates. Earlier this year we announced that Chrome will start
displaying warnings on insecure sites
, and we recently introduced
fully managed SSL certificates in App Engine
. And today we’re proud to announce that we are beginning to use another tool in our toolbox, the
HTTPS Strict Transport Security (HSTS) preload list
, in a new and more impactful way.
The HSTS preload list is built in to all major browsers (Chrome, Firefox, Safari, Internet Explorer/Edge, and Opera). It consists of a list of hostnames for which browsers automatically enforce HTTPS-secured connections. For example, gmail.com is on the list, which means that the aforementioned browsers will never make insecure connections to Gmail; if the user types
http://gmail.com
, the browser first changes it to
https://gmail.com
before sending the request. This provides greater security because the browser never loads an http-to-https redirect page, which could be intercepted.
The HSTS preload list can contain individual domains or subdomains and even
top-level domains
(TLDs), which are added through the
HSTS website
. The TLD is the last part of the domain name, e.g., .com, .net, or .org.
Google operates 45 TLDs
, including .google, .how, and .soy. In 2015 we created the first secure TLD when we added .google to the HSTS preload list, and we are now rolling out HSTS for a larger number of our TLDs, starting with .foo and .dev.
The use of TLD-level HSTS allows such namespaces to be secure by default. Registrants receive guaranteed protection for themselves and their users simply by choosing a secure TLD for their website and configuring an SSL certificate, without having to add individual domains or subdomains to the HSTS preload list. Moreover, since it typically takes months between adding a domain name to the list and browser upgrades reaching a majority of users, using an already-secured TLD provides immediate protection rather than eventual protection. Adding an entire TLD to the HSTS preload list is also more efficient, as it secures all domains under that TLD without the overhead of having to include all those domains individually.
We hope to make some of these secure TLDs available for registration soon, and would like to see TLD-wide HSTS become the security standard for new TLDs.
Updated 2017-10-06
: To clear up some confusion in the responses to this post, we are not rolling out HSTS to Google's previously launched open TLDs (.how, .soy, and .みんな).
Safe Browsing: Protecting more than 3 billion devices worldwide, automatically
September 11, 2017
Posted by Stephan Somogyi, Safe Browsing Emeritus and Allison Miller, Security & Privacy
[Cross-posted from
The Keyword
]
In 2007, we
launched
Safe Browsing, one of Google’s earliest anti-malware efforts. To keep our users safe, we’d show them a warning before they visited a site that might’ve harmed their computers.
Computing has evolved a bit in the last decade, though. Smartphones created a more mobile internet, and now AI is increasingly changing how the world interacts with it. Safe Browsing also had to evolve to effectively protect users.
And it has: In May 2016, we announced that
Safe Browsing
was protecting more than 2 billion devices from badness on the internet. Today we’re announcing that Safe Browsing has crossed the threshold to 3 billion devices. We’re sharing a bit more about how we got here, and where we’re going.
What is Safe Browsing?
You may not know Safe Browsing by name, since most of the time we’re invisibly protecting you, without getting in the way. But you may have seen a warning like this at some point:
This notification is one of the visible parts of Safe Browsing, a collection of Google technologies that hunt badness—typically websites that deceive users—on the internet. We identify sites that might try to phish you, or sites that install malware or other undesirable software. The systems that make up Safe Browsing work together to identify, analyze and continuously keep Safe Browsing’s knowledge of the harmful parts of the internet up to date.
This protective information that we generate—a curated list of places that are dangerous for people and their devices—is used across many of our products. It helps keep search results safe and keep ads free from badness; it’s integral to Google Play Protect and keeps you safe on Android; and it helps Gmail shield you from malicious messages.
And Safe Browsing doesn’t protect only Google’s products. For many years, Safari and Firefox have protected their users with Safe Browsing as well. If you use an up-to-date version of Chrome, Firefox or Safari, you’re protected by default. Safe Browsing is also used widely by
web developers
and
app developers
(
including Snapchat
), who integrate our protections by checking URLs before they’re presented to their users.
Protecting more people with fewer bits
In the days when web browsers were used only on personal computers, we didn’t worry much about the amount of data Safe Browsing sent over the internet to keep your browser current. Mobile devices changed all that: Slow connections, expensive mobile data plans, and scarce battery capacity became important new considerations.
So over the last few years, we’ve rethought how Safe Browsing delivers data. We built new technologies to make its data as compact as possible: We only send the information that’s most protective to a given device, and we make sure this data is compressed as tightly as possible. (All this work benefits desktop browsers, too!)
We initially introduced our new mobile-optimized method in
late 2015 with Chrome on Android,
made it
more broadly available in mid-2016
, when we also started a
ctively encouraging Android developers
to integrate it. With the release of iOS 10 in September 2016, Safari began using our new, efficient Safe Browsing update technology, giving iOS users a protection boost.
Safe Browsing in an AI-first world
The internet is at the start of another major shift. Safe Browsing has already been
using machine learning
for
many years
to detect
much badness
of
many kinds
. We’re continually evaluating and integrating cutting-edge new approaches to improve Safe Browsing.
Protecting all users across all their platforms makes the internet safer for everyone. Wherever the future of the internet takes us, Safe Browsing will be there, continuing to evolve, expand, and protect people wherever they are.
Chrome’s Plan to Distrust Symantec Certificates
September 11, 2017
Posted by Devon O’Brien, Ryan Sleevi, Andrew Whalley, Chrome Security
This post is a broader announcement of
plans already finalized
on the
blink-dev mailing list
.
Update, 1/31/18: Post was updated to further clarify 13 month validity limitations
At the end of July, the Chrome team and the PKI community converged upon a
plan
to reduce, and ultimately remove, trust in Symantec’s infrastructure in order to uphold users’ security and privacy when browsing the web. This plan, arrived at after significant debate on the blink-dev forum, would allow reasonable time for a transition to new, independently-operated Managed Partner Infrastructure while Symantec modernizes and redesigns its infrastructure to adhere to industry standards. This post reiterates this plan and includes a timeline detailing when site operators may need to obtain new certificates.
On January 19, 2017,
a public posting
to the mozilla.dev.security.policy newsgroup drew attention to a series of questionable website authentication certificates issued by Symantec Corporation’s PKI. Symantec’s PKI business, which operates a series of Certificate Authorities under various brand names, including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, had issued numerous certificates that did not comply with the industry-developed
CA/Browser Forum Baseline Requirements
. During the subsequent investigation, it was revealed that Symantec had entrusted several organizations with the ability to issue certificates without the appropriate or necessary oversight, and had been aware of security deficiencies at these organizations for some time.
This incident, while distinct from a
previous incident in 2015
, was part of a continuing pattern of
issues
over the past several years that has caused the Chrome team to lose confidence in the trustworthiness of Symantec’s infrastructure, and as a result, the certificates that have been or will be issued from it.
After our agreed-upon proposal was circulated, Symantec announced the selection of DigiCert to run this independently-operated Managed Partner Infrastructure, as well as their intention to sell their PKI business to DigiCert in lieu of building a new trusted infrastructure. This post outlines the timeline for that transition and the steps that existing Symantec customers should take to minimize disruption to their users.
Information For Site Operators
Starting with Chrome 66, Chrome will remove trust in Symantec-issued certificates issued prior to June 1, 2016. Chrome 66 is currently
scheduled
to be released to Chrome Beta users on March 15, 2018 and to Chrome Stable users around April 17, 2018.
If you are a site operator with a certificate issued by a Symantec CA prior to June 1, 2016, then prior to the release of Chrome 66, you will need to replace the existing certificate with a new certificate from any Certificate Authority trusted by Chrome.
Additionally, by December 1, 2017, Symantec will transition issuance and operation of publicly-trusted certificates to DigiCert infrastructure, and certificates issued from the old Symantec infrastructure after this date will not be trusted in Chrome.
Around the week of October 23, 2018, Chrome 70 will be released, which will fully remove trust in Symantec’s old infrastructure and all of the certificates it has issued. This will affect any certificate chaining to Symantec roots, except for the small number issued by the independently-operated and audited subordinate CAs previously disclosed to Google.
Site operators that need to obtain certificates from Symantec’s existing root and intermediate certificates may do so from the old infrastructure until December 1, 2017, although these certificates will need to be replaced again prior to Chrome 70. Additionally, certificates issued using validation information from Symantec’s infrastructure will have their validity limited to 13 months. Alternatively, site operators may obtain replacement certificates from any other Certificate Authority currently trusted by Chrome, which are unaffected by this distrust or validity period limit.
Reference Timeline
The following is a timeline of relevant dates associated with this plan, which distills the various requirements and milestones into an actionable set of information for site operators. As always, Chrome release dates can vary by a number of days, but upcoming release dates can be tracked
here
.
Date
Event
Now
through
~March 15, 2018
Site Operators using Symantec-issued TLS server certificates issued before June 1, 2016 should replace these certificates. These certificates can be replaced by any currently trusted CA.
~October 24, 2017
Chrome 62 released to Stable, which will add alerting in DevTools when evaluating certificates that will be affected by the Chrome 66 distrust.
December 1, 2017
According to Symantec, DigiCert’s new “Managed Partner Infrastructure” will at this point be capable of full issuance. Any certificates issued by Symantec’s old infrastructure after this point will cease working in a future Chrome update.
From this date forward, Site Operators can obtain TLS server certificates from the new Managed Partner Infrastructure that will continue to be trusted after Chrome 70 (~October 23, 2018).
December 1, 2017 does not mandate any certificate changes, but represents an opportunity for site operators to obtain TLS server certificates that will not be affected by Chrome 70’s distrust of the old infrastructure.
~March 15, 2018
Chrome 66 released to beta, which will remove trust in Symantec-issued certificates with a not-before date prior to June 1, 2016. As of this date Site Operators must be using either a Symantec-issued TLS server certificate issued on or after June 1, 2016 or a currently valid certificate issued from any other trusted CA as of Chrome 66.
Site Operators that obtained a certificate from Symantec’s old infrastructure after June 1, 2016 are unaffected by Chrome 66 but will need to obtain a new certificate by the Chrome 70 dates described below.
~April 17, 2018
Chrome 66 released to Stable.
~September 13, 2018
Chrome 70 released to Beta, which will remove trust in the old Symantec-rooted Infrastructure. This will not affect any certificate chaining to the new Managed Partner Infrastructure, which Symantec has said will be operational by December 1, 2017.
Only TLS server certificates issued by Symantec’s old infrastructure will be affected by this distrust regardless of issuance date.
~October 23, 2018
Chrome 70 released to Stable.
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
hacking
interoperability
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
2022
May
Apr
Mar
Feb
Jan
2021
Dec
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