Security Blog
The latest news and insights from Google on security and safety on the Internet
Protecting Gmail in a global world
August 12, 2014
Last week
we announced support
for non-Latin characters in Gmail—think δοκιμή and 测试 and みんな—as a first step towards more global email. We’re really excited about these new capabilities. We also want to ensure they aren’t abused by spammers or scammers trying to send misleading or harmful messages.
Scammers can exploit the fact that
ဝ
,
૦
, and
ο
look nearly identical to the letter
o
, and by mixing and matching them, they can hoodwink unsuspecting victims.* Can you imagine the risk of clicking “Sh
ဝ
ppingSite” vs. “ShoppingSite” or “MyBank” vs. “MyB
ɑ
nk”?
To stay one step ahead of spammers, the Unicode community has identified suspicious combinations of letters that could be misleading, and Gmail will now begin rejecting email with such combinations. We’re using an open standard—the
Unicode Consortium
’
s “Highly Restricted” specification
—which we believe strikes a healthy balance between legitimate uses of these new domains and those likely to be abused.
We’re rolling out the
changes
today, and hope that others across the industry will follow suit. Together, we can help ensure that international domains continue to flourish, allowing both users and businesses to have a
tête-à-tête
in the language of their choosing.
Posted by Mark Risher, Spam & Abuse Team
*For those playing at home, that's a Myanmar letter Wa (U+101D), a Gujarati digit zero (U+AE6) and a Greek small letter omicron (U+03BF), followed by the ASCII letter 'o'.
HTTPS as a ranking signal
August 7, 2014
Cross-posted from the
Webmaster Central Blog
Security is a top priority for Google. We invest a lot in making sure that our services use industry-leading security, like
strong HTTPS encryption by default
. That means that people using Search, Gmail and Drive, for example, automatically have a secure connection to Google.
Beyond our own stuff, we’re also working to make the Internet safer more broadly. A big part of that is making sure that websites people access from Google are secure. For instance, we have created resources to help webmasters
prevent and fix security breaches
on their sites.
We want to go even further. At
Google I/O
a few months ago, we called for “
HTTPS everywhere
” on the web.
We’ve also seen more and more webmasters adopting
HTTPS
(also known as HTTP over
TLS
, or Transport Layer Security), on their website, which is encouraging.
For these reasons, over the past few months we’ve been running tests taking into account whether sites use secure, encrypted connections as a signal in our search ranking algorithms. We’ve seen positive results, so we’re starting to use HTTPS as a ranking signal. For now it's only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as
high-quality content
—while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.
In the coming weeks, we’ll publish detailed best practices (we’ll add a link to it from here) to make TLS adoption easier, and to avoid common mistakes. Here are some basic tips to get started:
Decide the kind of certificate you need: single, multi-domain, or wildcard certificate
Use 2048-bit key certificates
Use relative URLs for resources that reside on the same secure domain
Use protocol relative URLs for all other domains
Check out our
Site move article
for more guidelines on how to change your website’s address
Don’t block your HTTPS site from crawling using robots.txt
Allow indexing of your pages by search engines where possible. Avoid the noindex robots meta tag
If your website is already serving on HTTPS, you can test its security level and configuration with the
Qualys Lab tool
. If you are concerned about TLS and your site’s performance, have a look at
Is TLS fast yet?
. And of course, if you have any questions or concerns, please feel free to post in our
Webmaster Help Forums
.
We hope to see more websites using HTTPS in the future. Let’s all make the web more secure!
Posted by
Zineb Ait Bahajji
and
Gary Illyes
, Webmaster Trends Analysts
Announcing Project Zero
July 15, 2014
Posted by Chris Evans, Researcher Herder
Security is a top priority for Google. We've invested a lot in making our products secure, including
strong SSL encryption by default
for Search, Gmail and Drive, as well as encrypting data moving between our data centers. Beyond securing our own products, interested Googlers also spend some of their time on
research that makes the Internet safer
, leading to the discovery of bugs like Heartbleed.
The success of that part-time research has led us to create a new, well-staffed team called Project Zero.
You should be able to use the web without fear that a criminal or state-sponsored actor is exploiting software bugs to infect your computer, steal secrets or monitor your communications. Yet in sophisticated attacks, we see the use of
"zero-day" vulnerabilities
to target, for example,
human rights activists
or to conduct
industrial espionage
. This needs to stop. We think more can be done to tackle this problem.
Project Zero is our contribution, to start the ball rolling. Our objective is to significantly reduce the number of people harmed by targeted attacks. We're hiring the best practically-minded security researchers and contributing 100% of their time toward improving security across the Internet.
We're not placing any particular bounds on this project and will work to improve the security of
any
software depended upon by large numbers of people, paying careful attention to the techniques, targets and motivations of attackers. We'll use standard approaches such as locating and reporting large numbers of vulnerabilities. In addition, we'll be conducting new research into mitigations, exploitation, program analysis—and anything else that our researchers decide is a worthwhile investment.
We commit to doing our work transparently. Every bug we discover will be filed in an
external database
. We will only report bugs to the software's vendor—and no third parties. Once the bug report becomes public (typically once a patch is available), you'll be able to monitor vendor time-to-fix performance, see any discussion about exploitability, and view historical exploits and crash traces. We also commit to sending bug reports to vendors in as close to real-time as possible, and to working with them to get fixes to users in a reasonable time.
We're hiring. We believe that most security researchers do what they do because they love what they do. What we offer that we think is new is a place to do what you love—but in the open and without distraction. We'll also be looking at ways to involve the wider community, such as extensions of our popular reward initiatives and guest blog posts. As we find things that are particularly interesting, we'll discuss them on
our blog
, which we hope you'll follow.
Maintaining digital certificate security
July 8, 2014
Posted by Adam Langley, Security Engineer
On Wednesday, July 2, we became aware of unauthorized digital certificates for several Google domains. The certificates were issued by the
National Informatics Centre
(NIC) of India, which holds several intermediate CA certificates trusted by the
Indian Controller of Certifying Authorities
(India CCA).
The India CCA certificates are
included in the Microsoft Root Store
and thus are trusted by the vast majority of programs running on Windows, including Internet Explorer and Chrome. Firefox is not affected because it uses its own root store that doesn’t include these certificates.
We are not aware of any other root stores that include the India CCA certificates, thus Chrome on other operating systems, Chrome OS, Android, iOS and OS X are not affected. Additionally, Chrome on Windows would not have accepted the certificates for Google sites because of
public-key pinning
, although misissued certificates for other sites may exist.
We promptly alerted NIC, India CCA and Microsoft about the incident, and we blocked the misissued certificates in Chrome with a
CRLSet
push.
On July 3, India CCA informed us that they revoked all the NIC intermediate certificates, and another CRLSet push was performed to include that revocation.
Chrome users do not need to take any action to be protected by the CRLSet updates. We have no indication of widespread abuse and we are not suggesting that people change passwords.
At this time, India CCA is still investigating this incident. This event also highlights, again, that our
Certificate Transparency
project is critical for protecting the security of certificates in the future.
Update Jul 9:
India CCA informed us of the results of their investigation on July 8. They reported that NIC’s issuance process was compromised and that only four certificates were misissued; the first on June 25. The four certificates provided included three for Google domains (one of which we were previously aware of) and one for Yahoo domains. However, we are also aware of misissued certificates not included in that set of four and can only conclude that the scope of the breach is unknown.
The intermediate CA certificates held by NIC were revoked on July 3, as noted above. But a root CA is responsible for all certificates issued under its authority. In light of this, in a future Chrome release, we will limit the India CCA root certificate to the following domains and subdomains thereof in order to protect users:
gov.in
nic.in
ac.in
rbi.org.in
bankofindia.co.in
ncode.in
tcs.co.in
Google Drive update to protect to shared links
June 27, 2014
Posted by Kevin Stadmeyer, Technical Program Manager
At Google, ensuring the security of our users is a top priority, and we are constantly assessing how we can make our services even more secure. We recently received a report via our
Vulnerability Reward Program
of a security issue affecting a small subset of file types in Google Drive and have since made an update to address it.
This issue is only relevant if
all
of the following apply:
The file was uploaded to Google Drive
The file was
not
converted to Docs, Sheets, or Slides (i.e. remained in its original format such as .pdf, .docx, etc.)
The owner changed sharing settings so that the document was available to “Anyone with the link”
The file contained hyperlinks to third-party
HTTPS
websites in its content
In this specific instance, if a user clicked on the embedded hyperlink, the administrator of that third-party site could potentially receive header information that may have allowed him or her to see the URL of the original document that linked to his or her site.
Today’s update to Drive takes extra precaution by ensuring that newly shared documents with hyperlinks to third-party HTTPS websites will not inadvertently relay the original document’s URL.
While any documents shared going forward are no longer impacted by this issue, if one of your previously shared documents meets all four of the criteria above, you can generate a new sharing link with the following steps:
Create a copy of the document, via File > "Make a copy..."
Share the copy of the document with particular people or via a new shareable link, via the “Share” button
Delete the original document
See what your apps & extensions have been up to
June 10, 2014
Cross-posted from the
Chromium Blog
Extensions are a great way to enhance the browsing experience. However, some extensions ask for broad permissions that allow access to sensitive data such as browser cookies or history. Last year, we
introduced
the
Chrome Apps & Extensions Developer Tool
, which provides an improved developer experience for debugging apps and extensions. The newest version of the tool, available today, lets power users audit any app or extension and get visibility into the precise actions that it's performing.
Once you’ve installed the Chrome Apps & Extensions Developer Tool, it will start locally auditing your extensions and apps as you use them. For each app or extension, you can see historical activity over the past few days as well as real-time activity by clicking the “Behavior” link. The tool highlights activities that involve your information, such as reading website cookies or modifying web sites, in a privacy section. You can also search for URLs to see if an extension has modified any matching pages. If you’re debugging an app or extension, you can use the “Realtime” tab to watch the stream of API calls as an extension or app runs. This can help you track down glitches or identify unnecessary API calls.
Whether you’re a Chrome power user or a developer testing an extension, the Chrome Apps & Extensions Developer Tool can give you the information you need to understand how apps and extensions affect your browsing.
Posted by Adrienne Porter Felt, Software Engineer and Extension Tinkerer
Making end-to-end encryption easier to use
June 3, 2014
posted by Stephan Somogyi, Product Manager, Security and Privacy
Your security online has always been a top priority for us, and we’re constantly working to make sure your data is safe. For example, Gmail supported
HTTPS
when it first launched and now
always uses an encrypted connection
when you check or send email in your browser. We warn people
in Gmail
and
Chrome
when we have reason to believe they’re being targeted by bad actors. We also alert you to
malware and phishing
when we find it.
Today, we’re adding to that list the alpha version of a new tool. It’s called
End-to-End
and it’s a Chrome extension intended for users who need additional security beyond what we already provide.
“End-to-end” encryption means data leaving your browser will be encrypted until the message’s intended recipient decrypts it, and that similarly encrypted messages sent to you will remain that way until you decrypt them in your browser.
While end-to-end encryption tools like
PGP
and
GnuPG
have been around for a long time, they require a great deal of technical know-how and manual effort to use. To help make this kind of encryption a bit easier, we’re releasing
code
for a new Chrome extension that uses
OpenPGP
, an open standard supported by many existing encryption tools.
However, you won’t find the End-to-End extension in the
Chrome Web Store
quite yet; we’re just sharing the code today so that the community can test and evaluate it, helping us make sure that it’s as secure as it needs to be before people start relying on it. (And we mean it: our
Vulnerability Reward Program
offers financial awards for finding security bugs in Google code, including End-to-End.)
Once we feel that the extension is ready for primetime, we’ll make it available in the
Chrome Web Store
, and anyone will be able to use it to send and receive end-to-end encrypted emails through their existing web-based email provider.
We recognize that this sort of encryption will probably only be used for very sensitive messages or by those who need added protection. But we hope that the End-to-End extension will make it quicker and easier for people to get that extra layer of security should they need it.
You can find more technical details describing how we've architected and implemented End-to-End
here
.
Speeding up and strengthening HTTPS connections for Chrome on Android
April 24, 2014
Posted by Elie Bursztein, Anti-Abuse Research Lead
Earlier this year, we deployed a new TLS cipher suite in Chrome that operates three times faster than AES-GCM on devices that don’t have AES hardware acceleration, including most Android phones, wearable devices such as Google Glass and older computers. This improves user experience, reducing latency and saving battery life by cutting down the amount of time spent encrypting and decrypting data.
To make this happen, Adam Langley, Wan-Teh Chang, Ben Laurie and I began implementing new algorithms -- ChaCha 20 for symmetric encryption and Poly1305 for authentication -- in OpenSSL and NSS in March 2013. It was a complex effort that required implementing a new abstraction layer in OpenSSL in order to support the Authenticated Encryption with Associated Data (AEAD) encryption mode properly. AEAD enables encryption and authentication to happen concurrently, making it easier to use and optimize than older, commonly-used modes such as CBC. Moreover,
recent attacks
against RC4 and CBC also prompted us to make this change.
The benefits of this new cipher suite include:
Better security: ChaCha20 is immune to padding-oracle attacks, such as the Lucky13, which affect CBC mode as used in TLS. By design, ChaCha20 is also immune to timing attacks. Check out a detailed description of TLS ciphersuites weaknesses in our earlier
post
.
Better performance: ChaCha20 and Poly1305 are very fast on mobile and wearable devices, as their designs are able to leverage common CPU instructions, including ARM vector instructions. Poly1305 also saves network bandwidth, since its output is only 16 bytes compared to HMAC-SHA1, which is 20 bytes. This represents a 16% reduction of the TLS network overhead incurred when using older ciphersuites such as RC4-SHA or AES-SHA. The expected acceleration compared to AES-GCM for various platforms is summarized in the chart below.
As of February 2014, almost all HTTPS connections made from Chrome browsers on Android devices to Google properties have used this new cipher suite. We plan to make it available as part of the Android platform in a future release. If you’d like to verify which cipher suite Chrome is currently using, on an Android device or on desktop, just click on the padlock in the URL bar and look at the connection tab. If Chrome is using ChaCha20-Poly1305 you will see the following information:
ChaCha20 and Poly1305 were designed by Prof. Dan Bernstein from the University of Illinois at Chicago. The simple and efficient design of these algorithms combined with the extensive vetting they received from the scientific community make us confident that these algorithms will bring the security and speed needed to secure mobile communication. Moreover, selecting algorithms that are free for everyone to use is also in line with our commitment to openness and transparency.
We would like to thank the people who made this possible: Dan Bernstein who invented and implemented both ChaCha/20 and Poly1305, Andrew Moon for his open-source implementation of Poly1305, Ted Krovetz for his open-source implementation of ChaCha20 and Peter Schwabe for his implementation work. We hope there will be even
greater adoption
of this cipher suite, and look forward to seeing other websites deprecate AES-SHA1 and RC4-SHA1 in favor of AES-GCM and ChaCha20-Poly1305 since they offer safer and faster alternatives. IETF draft standards for this cipher suite are available
here
and
here
.
New Security Measures Will Affect Older (non-OAuth 2.0) Applications
April 23, 2014
Posted by Antonio Fuentes, Product Manager, Google Identity Team
There is nothing more important than making sure our users and their information stay safe online. Doing that means providing security features at the user-level like 2-Step Verification and recovery options, and also involves a lot of work behind the scenes, both at Google and with developers like you. We've already implemented developer tools including
Google Sign-In
and support for
OAuth 2.0 in Google APIs
and IMAP, SMTP and XMPP, and we’re always looking to raise the bar.
That's why, beginning in the second half of 2014, we'll start gradually increasing the security checks performed when users log in to Google. These additional checks will ensure that only the intended user has access to their account, whether through a browser, device or application. These changes will affect any application that sends a username and/or password to Google.
To better protect your users, we recommend you upgrade all of your applications to OAuth 2.0. If you choose not to do so, your users will be required to take extra steps in order to keep accessing your applications.
The standard Internet protocols we support all work with OAuth 2.0, as do most of our APIs. We leverage the work done by the IETF on OAuth 2.0 integration with IMAP, SMTP, POP, XMPP, CalDAV, and CardDAV.
In summary, if your application currently uses plain passwords to authenticate to Google, we strongly encourage you to minimize user disruption by switching to
OAuth 2.0
.
Street View and reCAPTCHA technology just got smarter
April 16, 2014
Posted by Vinay Shet, Product Manager, reCAPTCHA
Have you ever wondered how Google Maps knows the exact location of your neighborhood coffee shop? Or of the hotel you’re staying at next month? Translating a street address to an exact location on a map is harder than it seems. To take on this challenge and make Google Maps even more useful, we’ve been working on a new system to help locate addresses even more accurately, using some of the technology from the Street View and reCAPTCHA teams.
This technology finds and reads street numbers in Street View, and correlates those numbers with existing addresses to pinpoint their exact location on Google Maps. We’ve described these findings in a
scientific paper
at the
International Conference on Learning Representations (ICLR)
. In this paper, we show that this system is able to accurately detect and read difficult numbers in Street View with 90% accuracy.
Street View numbers correctly identified by the algorithm
These findings have surprising implications for spam and abuse protection on the Internet as well. For more than a decade,
CAPTCHAs
have used visual puzzles in the form of distorted text to help webmasters prevent automated software from engaging in abusive activities on their sites. Turns out that this new algorithm can also be used to read CAPTCHA puzzles—we found that it can decipher the hardest distorted text puzzles from reCAPTCHA with over 99% accuracy. This shows that the act of typing in the answer to a distorted image should not be the only factor when it comes to determining a human versus a machine.
Fortunately, Google’s reCAPTCHA has taken this into consideration, and reCAPTCHA is more secure today than ever before. Last year, we
announced
that we’ve significantly reduced our dependence on text distortions as the main differentiator between human and machine, and instead perform advanced risk analysis. This has also allowed us to simplify both our text CAPTCHAs as well as our audio CAPTCHAs, so that getting through this security measure is easy for humans, but still keeps websites protected.
CAPTCHA images correctly solved by the algorithm
Thanks to this research, we know that relying on distorted text alone isn’t enough. However, it’s important to note that simply identifying the text in CAPTCHA puzzles correctly doesn’t mean that reCAPTCHA itself is broken or ineffective. On the contrary, these findings have helped us build additional safeguards against bad actors in reCAPTCHA.
As the Street View and reCAPTCHA teams continue to work closely together, both will continue to improve, making Maps more precise and useful and reCAPTCHA safer and more effective. For more information, check out the
reCAPTCHA site
and the
scientific paper
from
ICLR 2014
.
Labels
#sharethemicincyber
#supplychain #security #opensource
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
2024
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2023
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2022
Dec
Nov
Oct
Sep
Aug
Jul
Jun
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
.