Google Online Security Blog: 2014

An Update to End-To-End

16 December 2014

Posted by Stephan Somogyi, Product Manager, Security and Privacyannounced and launched End-To-End

We’re migrating End-To-End to GitHub. We’ve always believed strongly that End-To-End must be an open source project, and we think that using GitHub will allow us to work together even better with the community.

We’ve included several contributions from Yahoo Inc. Alex Stamos, Yahoo’s Chief Security Officer, announced at BlackHat 2014 in August that his team would be participating in our End-To-End project; we’re very happy to release the first fruits of this collaboration.

We’ve added more documentation. The project wiki now contains additional information about End-To-End, both for developers as well as security researchers interested in understanding better how we think about End-To-End’s security model.

Vulnerability Rewards Program

Reject the Unexpected - Content Security Policy in Gmail

16 December 2014

Posted by Danesh Irani, Software Engineer, Gmail Security(Cross-posted from the Gmail Blog)serving images through secure proxy serversrequiring HTTPSthe Chrome Web StoreGoogle Security CenterThis post was updated on December 18th to add a description of the XSS defense benefit of CSP, and to more precisely define the interaction with extensions.

Are you a robot? Introducing “No CAPTCHA reCAPTCHA”

3 December 2014

Posted by Vinay Shet, Product Manager, reCAPTCHAreCAPTCHA

A brief history of CAPTCHAs our research recently showeddevelopedValentine’s Day postAre you sure you’re not a robot?

Making reCAPTCHAs mobile-friendlyComputer Vision

Adopting the new API on your siteSnapchatWordPressHumble Bundlevisit our site

Ready, aim, fire: an open-source tool to test web security scanners

18 November 2014

no bug expects ita talk at the Google Testing Automation Conference 2013some helpgithub.com/google/firing-rangepublic-firing-range.appspot.comcontributions and feedbacksPosted by Claudio Criscione, Security Engineer

Behind enemy lines in our war against account hijackers

6 November 2014

recent pollcontinue to work hardstate-sponsored attacksstudyphishing

Simple but dangerous: Most of us think we’re too smart to fall for phishing, but our research found some fake websites worked a whopping 45% of the time. On average, people visiting the fake pages submitted their info 14% of the time, and even the most obviously fake sites still managed to deceive 3% of people. Considering that an attacker can send out millions of messages, these success rates are nothing to sneeze at.

Quick and thorough: Around 20% of hijacked accounts are accessed within 30 minutes of a hacker obtaining the login info. Once they’ve broken into an account they want to exploit, hijackers spend more than 20 minutes inside, often changing the password to lock out the true owner, searching for other account details (like your bank, or social media accounts), and scamming new victims.

Personalized and targeted: Hijackers then send phishing emails from the victim’s account to everyone in his or her address book. Since your friends and family think the email comes from you, these emails can be very effective. People in the contact list of hijacked accounts are 36 times more likely to be hijacked themselves.

Learning fast: Hijackers quickly change their tactics to adapt to new security measures. For example, after we started asking people to answer questions (like “which city do you login from most often?”) when logging in from a suspicious location or device, hijackers almost immediately started phishing for the answers.

We’ve used the findings from this study, along with our ongoing research efforts, to improve the many account security systems we have in place. But we can use your help too.

Stay vigilant: Gmail blocks the vast majority of spam and phishing emails, but be wary of messages asking for login information or other personal data. Never reply to these messages; instead, report them to us. When in doubt, visit websites directly (not through a link in an email) to review or update account information.

Get your account back fast: If your account is ever at risk, it’s important that we have a way to get in touch with you and confirm your ownership. That’s why we strongly recommend you provide a backup phone number or a secondary email address (but make sure that email account uses a strong password and is kept up to date so it’s not released due to inactivity).

2-step verification: Our free 2-step verification service provides an extra layer of security against all types of account hijacking. In addition to your password, you’ll use your phone to prove you’re really you. We also recently added an option to log in with a physical USB device.

Take a few minutes and visit the Secure Your Account page, where you can make sure we’ve got backup contact info for you and confirm that your other security settings are up to date.

Posted by Elie Bursztein, Anti-Abuse Research Lead

click to see full-size infographic

Introducing nogotofail—a network traffic security testing tool

4 November 2014

HTTPS everywhere
The Android Security Team has built a tool, called nogotofail, that provides an easy way to confirm that the devices or applications you are using are safe against known TLS/SSL vulnerabilities and misconfigurations. Nogotofail works for Android, iOS, Linux, Windows, Chrome OS, OSX, in fact any device you use to connect to the Internet. There’s an easy-to-use client to configure the settings and get notifications on Android and Linux, as well as the attack engine itself which can be deployed as a router, VPN server, or proxy.
We’ve been using this tool ourselves for some time and have worked with many developers to improve the security of their apps. But we want the use of TLS/SSL to advance as quickly as possible. Today, we’re releasing it as an open source project, so anyone can test their applications, contribute new features, provide support for more platforms, and help improve the security of the Internet.

Posted by Chad Brubaker, Android Security Engineer

Learning statistics with privacy, aided by the flip of a coin

30 October 2014

Cross-posted on the Research Blog and the Chromium Blog
protect our users' security and privacyrandomized responsedifferential privacystrongest form of privacyintense research in academiaon the Internet, nobody should know you’re a dogunwanted softwarehijackingopen-source projectreportACM Conference on Computer and Communications Securityfeedbackrappor-discuss@googlegroups.comPosted by Úlfar Erlingsson, Tech Lead Manager, Security Research

Strengthening 2-Step Verification with Security Key

21 October 2014

2-Step VerificationSecurity Key

Security Key and Chrome incorporate the open Universal 2nd Factor (U2F) protocol from the FIDO Alliance, so other websites with account login systems can get FIDO U2F working in Chrome today. It’s our hope that other browsers will add FIDO U2F support, too. As more sites and browsers come onboard, security-sensitive users can carry a single Security Key that works everywhere FIDO U2F is supported.learn morePosted by Nishit Shah, Product Manager, Google Security

This POODLE bites: exploiting the SSL 3.0 fallback

14 October 2014

detailsTLS_FALLBACK_SCSVPosted by Bodo Möller, Google Security Team
[Updated Oct 15 to note that SSL 3.0 is nearly 18 years old, not nearly 15 years old.]

News from the land of patch rewards

9 October 2014

launchedPatch Reward
We started with a modest scope and reward amounts, but have gradually expanded the program over the past few months. We’ve seen some great work so far—and to help guide future submissions, we wanted to share some of our favorites:

Incorporation of a variety of web security checks directly into Django to help users develop safer web applications.

A support for seccomp-bpf sandboxing in BIND to minimize the impact of remote code execution bugs.

Addition of Curve25519 and several other primitives in OpenSSH to strengthen its cryptographic foundations and improve performance.

A set of patches to reduce the likelihood of ASLR info leaks in Linux to make certain types of memory corruption bugs more difficult to exploit.

And, of course, the recent attack-surface-reducing function prefix patch in bash that helped mitigate a flurry of “Shellshock”-related bugs.

We hope that this list inspires even more contributions in the year to come. Of course, before participating, be sure to read the rules page. When done, simply send your nominations to security-patches@google.com. And keep up the great work!
Posted by Michal Zalewski, Google Security Team

An update to SafeSearch options for network administrators

2 October 2014

strong SSL encryption
For some time, we’ve offered network administrators the ability to require the use of SafeSearch by their users, which filters out explicit content from search results; this is especially important for schools. However, using this functionality has meant that searches were sent over an unencrypted connection to Google. Unfortunately, this has been the target of abuse by other groups looking to snoop on people’s searches, so we will be removing it as of early December.
Going forward, organizations can require SafeSearch on their networks while at the same time ensuring that their users’ connections to Google remain encrypted. (This is in addition to existing functionality that allows SafeSearch to be set on individual browsers and to be enabled by policy on managed devices like Chromebooks.) Network administrators can read more about how to enable this new feature here.
Posted by Brian Fitzpatrick, Engineering Director

Fewer bugs, mo’ money

30 September 2014

Cross-posted on the Chromium Blog
bug reward programsecure
This is a good problem to have! In recognition of the extra effort it takes to uncover vulnerabilities in Chrome, we’re increasing our reward levels. We’re also making some changes to be more transparent with researchers reporting a bug.

First, we’re increasing our usual reward pricing range to $500-$15,000 per bug, up from a previous published maximum of $5,000. This is accompanied with a clear breakdown of likely reward amounts by bug type. As always, we reserve the right to reward above these levels for particularly great reports. (For example, last month we awarded $30,000 for a very impressive report.)

Second, we’ll pay at the higher end of the range when researchers can provide an exploit to demonstrate a specific attack path against our users. Researchers now have an option to submit the vulnerability first and follow up with an exploit later. We believe that this a win-win situation for security and researchers: we get to patch bugs earlier and our contributors get to lay claim to the bugs sooner, lowering the chances of submitting a duplicate report.

Third, Chrome reward recipients will be listed in the Google Hall of Fame, so you’ve got something to print out and hang on the fridge.

As a special treat, we’re going to back-pay valid submissions from July 1, 2014 at the increased reward levels we’re announcing today. Good times.

We’ve also answered some new FAQs on our rules page, including questions about our new Trusted Researcher program and a bit about our philosophy and alternative markets for zero-day bugs.

Happy bug hunting!

Posted by Tim Willis, Hacker Philanthropist, Chrome Security Team

Security for the people

18 September 2014

Cross-posted on the Open Source Blog
A recent Pew study found that 86% of people surveyed had taken steps to protect their security online. This is great—more security is always good. However, if people are indeed working to protect themselves, why are we still seeing incidents, breaches, and confusion? In many cases these problems recur because the technology that allows people to secure their communications, content and online activity is too hard to use.

In other words, the tools for the job exist. But while many of these tools work technically, they don’t always work in ways that users expect. They introduce extra steps or are simply confusing and cumbersome. (“Is this a software bug, or am I doing something wrong?”) However elegant and intelligent the underlying technology (and much of it is truly miraculous), the results are in: if people can’t use it easily, many of them won’t.

We believe that people shouldn’t have to make a trade-off between security and ease of use. This is why we’re happy to support Simply Secure, a new organization dedicated to improving the usability and safety of open-source tools that help people secure their online lives.

Over the coming months, Simply Secure will be collaborating with open-source developers, designers, researchers, and others to take what’s there—groundbreaking work from efforts like Open Whisper Systems, The Guardian Project, Off-the-Record Messaging, and more—and work to make them easier to understand and use.

We’re excited for a future where people won’t have to choose between ease and security, and where tools that allow people to secure their communications, content, and online activity are as easy as choosing to use them.

Posted by Meredith Whittaker, Open Source Research Lead and Ben Laurie, Senior Staff Security Engineer

Cleaning up after password dumps

10 September 2014

We found that less than 2% of the username and password combinations might have worked, and our automated anti-hijacking systems would have blocked many of those login attempts. We’ve protected the affected accounts and have required those users to reset their passwords.
It’s important to note that in this case and in others, the leaked usernames and passwords were not the result of a breach of Google systems. Often, these credentials are obtained through a combination of other sources.
For instance, if you reuse the same username and password across websites, and one of those websites gets hacked, your credentials could be used to log into the others. Or attackers can use malware or phishing schemes to capture login credentials.

We’re constantly working to keep your accounts secure from phishing, malware and spam. For instance, if we see unusual account activity, we’ll stop sign-in attempts from unfamiliar locations and devices. You can review this activity and confirm whether or not you actually took the action.

A few final tips: Make sure you’re using a strong password unique to Google. Update your recovery options so we can reach you by phone or email if you get locked out of your account. And consider 2-step verification, which adds an extra layer of security to your account. You can visit g.co/accountcheckup where you’ll see a list of many of the security controls at your disposal.

Posted by Borbala Benko, Elie Bursztein, Tadek Pietraszek and Mark Risher, Google Spam & Abuse Team

Gradually sunsetting SHA-1

5 September 2014

Cross-posted on the Chromium Blog
since at least 2005Collision attacks against SHA-1 are too affordableBaseline Requirements for SSLNISTthe MD5 hash algorithmfrom leading vendorsscrambling for updates
Chrome 39 (Branch point 26 September 2014)

Sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

The current visual display for “secure, but with minor errors” is a lock with a yellow triangle, and is used to highlight other deprecated and insecure practices, such as passive mixed content.

Chrome 40 (Branch point 7 November 2014; Stable after holiday season)

Sites with end-entity certificates that expire between 1 June 2016 to 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “neutral, lacking security”.

The current visual display for “neutral, lacking security” is a blank page icon, and is used in other situations, such as HTTP.

Chrome 41 (Branch point in Q1 2015)

Sites with end-entity certificates that expire between 1 January 2016 and 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “affirmatively insecure”. Subresources from such domain will be treated as “active mixed content”.

The current visual display for “affirmatively insecure” is a lock with a red X, and a red strike-through text treatment in the URL scheme.

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

Posted by Chris Palmer, Secure Socket Lover and Ryan Sleevi, Transport Layer Securer

That’s not the download you’re looking for...

14 August 2014

Cross-posted on the Chrome Blog
Safe Browsing

these tips

Posted by Moheeb Abu Rajab, Staff Engineer, Google Security

Protecting Gmail in a global world

12 August 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

7 August 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

15 July 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

8 July 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

27 June 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

10 June 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.

Making end-to-end encryption easier to use

3 June 2014

posted by Stephan Somogyi, Product Manager, Security and Privacy

HTTPSalways uses an encrypted connectionin GmailChromemalware and phishingEnd-to-End
PGPGnuPGcodeOpenPGPChrome Web StoreVulnerability Reward ProgramChrome Web Storehere

Speeding up and strengthening HTTPS connections for Chrome on Android

24 April 2014

Posted by Elie Bursztein, Anti-Abuse Research Leadrecent attacks

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.

greater adoptionherehere

New Security Measures Will Affect Older (non-OAuth 2.0) Applications

23 April 2014

Posted by Antonio Fuentes, Product Manager, Google Identity TeamGoogle Sign-InOAuth 2.0 in Google APIsOAuth 2.0

Street View and reCAPTCHA technology just got smarter

16 April 2014

Posted by Vinay Shet, Product Manager, reCAPTCHA scientific paperInternational Conference on Learning Representations (ICLR)

Street View numbers correctly identified by the algorithm

CAPTCHAsannounced

CAPTCHA images correctly solved by the algorithm

reCAPTCHA sitescientific paperICLR 2014

Google Services Updated to Address OpenSSL CVE-2014-0160 (the Heartbleed bug)

9 April 2014

Posted by Matthew O'Connor, Product Manager
You may have heard of “Heartbleed,” a flaw in OpenSSL that could allow the theft of data normally protected by SSL/TLS encryption. We’ve assessed this vulnerability and applied patches to key Google services such as Search, Gmail, YouTube, Wallet, Play, Drive, Apps, App Engine, AdWords, DoubleClick, Maps, Maps Engine, Earth, Analytics and Tag Manager. Google Chrome and Chrome OS are not affected. We are still working to patch some other Google services. We regularly and proactively look for vulnerabilities like this -- and encourage others to report them -- so that that we can fix software flaws before they are exploited.
If you are a Google Cloud Platform or Google Search Appliance customer, or don’t use the latest version of Android, here is what you need to know:
Cloud SQLWe are currently patching Cloud SQL, with the patch rolling out to all instances today and tomorrow. In the meantime, users should use the IP whitelisting function to ensure that only known hosts can access their instances. Please find instructions here.
Google Compute Engine Customers need to manually update OpenSSL on each running instance or should replace any existing images with versions including an updated OpenSSL. Once updated, each instance should be rebooted to ensure all running processes are using the updated SSL library. Please find instructions here.

Google Search Appliance (GSA) Engineers have patched GSA and issued notices to customers. More information is available in the Google Enterprise Support Portal.

Android All versions of Android are immune to CVE-2014-0160 (with the limited exception of Android 4.1.1; patching information for Android 4.1.1 is being distributed to Android partners).

We will continue working closely with the security research and open source communities, as doing so is one of the best ways we know to keep our users safe. Apr 12Apr 14Google Enterprise Support PortalApr 16: Apr 28:

Google’s Public DNS intercepted in Turkey

29 March 2014

Posted by Steven Carstensen, Software Engineer
YouTube

If you could tell a user three things to do to stay safe online, what would they be?

26 March 2014

Posted by Rob Reeder, User Experience Research TeamSafety Centergoo.gl/F4fJ59

Security Blog