Posted by Steven Carstensen, Software Engineer

We have received several credible reports and confirmed with our own research that Google’s Domain Name System (DNS) service has been intercepted by most Turkish ISPs (Internet Service Providers).

A DNS server tells your computer the address of a server it’s looking for, in the same way that you might look up a phone number in a phone book. Google operates DNS servers because we believe that you should be able to quickly and securely make your way to whatever host you’re looking for, be it YouTube, Twitter, or any other.

But imagine if someone had changed out your phone book with another one, which looks pretty much the same as before, except that the listings for a few people showed the wrong phone number. That’s essentially what’s happened: Turkish ISPs have set up servers that masquerade as Google’s DNS service.

Posted by Rob Reeder, User Experience Research Team

At Google, we’re constantly trying to improve security for our users. Besides the many technical security features we build, our efforts include educating users with advice about what they can do to stay safe online. Our Safety Center is a great example of this. But we’re always trying to do better and have been looking for ways to improve how we provide security advice to users.

That’s why we’ve started a research project to try to pare down existing security advice to a small set of things we can realistically expect our users to do to stay safe online. As part of this project, we are currently running a survey of security experts to see what advice they think is most important.

If you work in security, we’d really appreciate your input. Please take our survey here: goo.gl/F4fJ59. 

With your input we can draw on our collective expertise to get closer to an optimal set of advice that users can realistically follow, and thus, be safer online. Thanks!

Posted by Nicolas Lidzborski, Gmail Security Engineering Lead

Cross-posted on the Official Google Blog and Gmail Blog

Your email is important to you, and making sure it stays safe and always available is important to us. As you go about your day reading, writing, and checking messages, there are tons of security measures running behind the scenes to keep your email safe, secure, and there whenever you need it.

Starting today, Gmail will always use an encrypted HTTPS connection when you check or send email. Gmail has supported HTTPS since the day it launched, and in 2010 we made HTTPS the default. Today's change means that no one can listen in on your messages as they go back and forth between you and Gmail’s servers—no matter if you're using public WiFi or logging in from your computer, phone or tablet.

In addition, every single email message you send or receive—100 percent of them—is encrypted while moving internally. This ensures that your messages are safe not only when they move between you and Gmail's servers, but also as they move between Google's data centers—something we made a top priority after last summer’s revelations.

Of course, being able to access your email is just as important as keeping it safe and secure. In 2013, Gmail was available 99.978 percent of the time, which averages to less than two hours of disruption for a user for the entire year. Our engineering experts look after Google's services 24x7 and if a problem ever arises, they're on the case immediately. We keep you informed by posting updates on the Apps Status Dashboard until the issue is fixed, and we always conduct a full analysis on the problem to prevent it from happening again.

Our commitment to the security and reliability of your email is absolute, and we’re constantly working on ways to improve. You can learn about additional ways to keep yourself safe online, like creating strong passwords and enabling 2-step verification, by visiting the Security Center: https://www.google.com/help/security.

Posted by Vinay Shet, Product Manager, reCAPTCHA

Notice something different about reCAPTCHA today? You guessed it; those tricky puzzles are now warm and fuzzy just in time for Valentine’s Day. Today across the U.S., we're sharing CAPTCHAs that spread the message of love.

Some examples of Valentine's Day CAPTCHAs

But wait. These look really easy. Does this mean that those pesky bots are going to crack these easy CAPTCHAs and abuse our favorite websites? Not so fast.

A few months ago, we announced an improved version of reCAPTCHA that uses advanced risk analysis techniques to distinguish humans from machines. This enabled us to relax the text distortions and show our users CAPTCHAs that adapt to their risk profiles. In other words, with a high likelihood, our valid human users would see CAPTCHAs that they would find easy to solve. Abusive traffic, on the other hand, would get CAPTCHAs designed to stop them in their tracks. It is this same technology that enables us to show these Valentine’s Day CAPTCHAs today without reducing their anti-abuse effectiveness.

But that’s not all. Over the last few months, we’ve been working hard to improve the audio CAPTCHA experience. Our adaptive CAPTCHA technology has, in many cases, allowed us to relax audio distortions and serve significantly easier audio CAPTCHAs. We’ve served over 10 million easy audio CAPTCHAs to users worldwide over the last few weeks and have seen great success rates. We hope to continue enhancing our accessibility option in reCAPTCHA in the months to come. Take a listen to this sample of easy audio CAPTCHA:

  

We’re working hard to improve people’s experience with reCAPTCHA without compromising on the spam and abuse protection you’ve come to trust from us. For today, we hope you enjoy our Valentine’s Day gift to you.

Posted by Eduardo Vela Nava and Michal Zalewski, Google Security Team

From investing our time in doing security research to paying for security bugs and patches, we've really enjoyed and benefited from our involvement with the security community over the past few years. To underscore our commitment, we want to announce yet another increase in payments since we started our reward programs.

Starting today, we will broaden the scope of our vulnerability reward program to also include all Chrome apps and extensions developed and branded as "by Google." We think developing Chrome extensions securely is relatively easy (given our security guidelines are followed), but given that extensions like Hangouts and GMail are widely used, we want to make sure efforts to keep them secure are rewarded accordingly.

The rewards for each vulnerability will range from the usual $500 up to $10,000 USD and will depend on the permissions and the data each extension handles. If you find a vulnerability in any Google-developed Chrome Extensions, please contact us at goo.gl/vulnz.

In addition, we decided to substantially increase the reward amounts offered by our Patch Reward Program. The program encourages and honors proactive security improvements made to a range of open-source projects that are critical to the health of the Internet in recognition of the painstaking work that's necessary to make a project resilient to attacks.

Our new reward structure is:

• $10,000 for complicated, high-impact improvements that almost certainly prevent major vulnerabilities in the affected code. 
• $5,000 for moderately complex patches that provide convincing security benefits.
• Between $500 and $1,337 for submissions that are very simple or that offer only fairly speculative gains. 

We look forward to ongoing collaboration with the broader security community, and we'll continue to invest in these programs to help make the Internet a safer place for everyone.

Posted by Philipp Pfeiffenberger, Software Engineer 

YouTube isn’t just a place for videos, it’s a place for meaningful human interaction. Whether it’s views, likes, or comments, these interactions both represent and inform how creators connect with their audience. That’s why we take the accuracy of these interactions very seriously. When some bad actors try to game the system by artificially inflating view counts, they’re not just misleading fans about the popularity of a video, they’re undermining one of YouTube’s most important and unique qualities.

As part of our long-standing effort to keep YouTube authentic and full of meaningful interactions, we’ve begun periodically auditing the views a video has received. While in the past we would scan views for spam immediately after they occurred, starting today we will periodically validate the video’s view count, removing fraudulent views as new evidence comes to light. We don’t expect this approach to affect more than a minuscule fraction of videos on YouTube, but we believe it’s crucial to improving the accuracy of view counts and maintaining the trust of our fans and creators.

As YouTube creators, we ask you to be extra careful when working with third-party marketing firms; unfortunately some of them will sell you fake views. If you need help promoting your video, please review our posts about working with third party view service providers and increasing YouTube views.

Posted by Mateusz Jurczyk and Gynvael Coldwind, Information Security Engineers

At Google, security is a top priority - not only for our own products, but across the entire Internet. That’s why members of the Google Security Team and other Googlers frequently perform audits of software and report the resulting findings to the respective vendors or maintainers, as shown in the official “Vulnerabilities - Application Security” list. We also try to employ the extensive computing power of our data centers in order to solve some of the security challenges by performing large-scale automated testing, commonly known as fuzzing.

One internal fuzzing effort we have been running continuously for the past two years is the testing process of FFmpeg, a large cross-platform solution to record, convert and stream audio and video written in C. It is used in multiple applications and software libraries such as Google Chrome, MPlayer, VLC or xine. We started relatively small by making use of trivial mutation algorithms, some 500 cores and input media samples gathered from readily available sources such as the samples.mplayerhq.hu sample base and FFmpeg FATE regression testing suite. Later on, we grew to more complex and effective mutation methods, 2000 cores and an input corpus supported by sample files improving the overall code coverage.

Following more than two years of work, we are happy to announce that the FFmpeg project has incorporated more than a thousand fixes to bugs (including some security issues) that we have discovered in the project so far:

$ git log | grep Jurczyk | grep -c Coldwind
1120

This event clearly marks an important milestone in our ongoing fuzzing effort.

FFmpeg robustness and security has clearly improved over time. When we started the fuzzing process and had initial results, we contacted the project maintainer - Michael Niedermayer - who submitted the first fix on the 24th of January, 2012 (see commit c77be3a35a0160d6af88056b0899f120f2eef38e). Since then, we have carried out several dozen fuzzing iterations (each typically resulting in less crashes than the previous ones) over the last two years, identifying bugs of a number of different classes:

• NULL pointer dereferences, 
• Invalid pointer arithmetic leading to SIGSEGV due to unmapped memory access, 
• Out-of-bounds reads and writes to stack, heap and static-based arrays, 
• Invalid free() calls, 
• Double free() calls over the same pointer, 
• Division errors, 
• Assertion failures, 
• Use of uninitialized memory. 

We have simultaneously worked with the developers of Libav, an independent fork of FFmpeg, in order to have both projects represent an equal, high level of robustness and security posture. Today, Libav is at 413 fixes and the library is slowly but surely catching up with FFmpeg.

We are continuously improving our corpus and fuzzing methods and will continue to work with both FFmpeg and Libav to ensure the highest quality of the software as used by millions of users behind multiple media players. Until we can declare both projects "fuzz clean" we recommend that people refrain from using either of the two projects to process untrusted media files. You can also use privilege separation on your PC or production environment when absolutely required.

Of course, we would not be able to do this without the hard work of all the developers involved in the fixing process. If you are interested in the effort, please keep an eye on the master branches for commits marked as "Found by Mateusz "j00ru" Jurczyk and Gynvael Coldwind" and watch out for new stable versions of the software packages.

For more details, see the “FFmpeg and a thousand fixes” posts at the authors’ personal blogs here or here.

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)]

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.

Posted by Michal Zalewski, Google Security Team

About a month ago, we kicked off our Patch Reward Program. The goal is very simple: to recognize and reward proactive security improvements to third-party open-source projects that are vital to the health of the entire Internet.

We started with a fairly conservative scope, but said we would expand the program soon. Today, we are adding the following to the list of projects that are eligible for rewards:

• All the open-source components of Android: Android Open Source Project
• Widely used web servers: Apache httpd, lighttpd, nginx
• Popular mail delivery services: Sendmail, Postfix, Exim, Dovecot
• Virtual private networking: OpenVPN
• Network time: University of Delaware NTPD
• Additional core libraries: Mozilla NSS, libxml2
• Toolchain security improvements for GCC, binutils, and llvm

For more information about eligibility, reward amounts, and the submission process, please visit this page. Happy patching!