We are hopeful that no one will encounter this error, since public CAs must stop issuing SHA-1 certificates in 2016 per the Baseline Requirements for SSL.
In addition, a later version of Chrome in 2016 may extend these criteria in order to help guard against SHA-1 collision attacks on older devices, by displaying a certificate error for sites with certificate chains that:
contain an intermediate or leaf certificate signed with a SHA-1-based signature
contain an intermediate or leaf certificate issued on or after January 1, 2016
chain to a public CA
(Note that the first two criteria can match different certificates.)
Note that sites using new SHA-1 certificates that chain to local trust anchors (rather than public CAs) will continue to work without a certificate error. However, they will still be subject to the UI downgrade specified in our original announcement.
Step 2: Blocking all SHA-1 certificates
Starting January 1, 2017 at the latest, Chrome will completely stop supporting SHA-1 certificates. At this point, sites that have a SHA-1-based signature as part of the certificate chain (not including the self-signature on the root certificate) will trigger a fatal network error. This includes certificate chains that end in a local trust anchor as well as those that end at a public CA.
In line with Microsoft Edge and Mozilla Firefox, the target date for this step is January 1, 2017, but we are considering moving it earlier to July 1, 2016 in light of ongoing research. We therefore urge sites to replace any remaining SHA-1 certificates as soon as possible.
Note that Chrome uses the certificate trust settings of the host OS where possible, and that an update such as Microsoft’s planned change will cause a fatal network error in Chrome, regardless of Chrome’s intended target date.
Keeping your site safe and compatible
As individual TLS features are found to be too weak, browsers need to drop support for those features to keep users safe. Unfortunately, SHA-1 certificates are not the only feature that browsers will remove in the near future.
As we announced on our security-dev mailing list, Chrome 48 will also stop supporting RC4 cipher suites for TLS connections. This aligns with timelines for Microsoft Edge and Mozilla Firefox.
For security and interoperability in the face of upcoming browser changes, site operators should ensure that their servers use SHA-2 certificates, support non-RC4 cipher suites, and follow TLS best practices. In particular, we recommend that most sites support TLS 1.2 and prioritize the ECDHE_RSA_WITH_AES_128_GCM cipher suite. We also encourage site operators to use tools like the SSL Labs server test and Mozilla's SSL Configuration Generator.
Although our systems prefer the HTTPS version by default, you can also make this clearer for other search engines by redirecting your HTTP site to your HTTPS version and by implementing the HSTS header on your server.
We’re excited about taking another step forward in making the web more secure. By showing users HTTPS pages in our search results, we’re hoping to decrease the risk for users to browse a website over an insecure connection and making themselves vulnerable to content injection attacks. As usual, if you have any questions or comments, please let us know in the comments section below or in our webmaster help forums.
Next, we had to better understand how UwS is being disseminated.
This varies quite a bit, but time and again, deception is at the heart of these tactics. Common UwS distribution tactics include: unwanted ad injection, misleading ads such as “trick-to-click”, ads disguised as ‘download’ or ‘play’ buttons, bad software downloader practices, misleading or missing disclosures about what the software does, hijacked browser default settings, annoying system pop-up messages, and more.
Here are a few specific examples:
Deceptive ads leading to UwS downloads
Ads from unwanted ads injector taking over a New York Times page and sending the user to phone scams
Unwanted ad injector inserts ads on the Google search results page
New tab page is overridden by UwS
UwS hijacks Chrome navigations and directs users to a scam tech support website
One year of progress
Because UwS touches so many different parts of people’s online experiences, we’ve worked to fight it on many different fronts. Weaving UwS detection into Safe Browsing has been critical to this work, and we’ve pursued other efforts as well—here’s an overview:
We now include UwS in Safe Browsing and its API, enabling people who use Chrome and other browsers to see warnings before they go to sites that contain UwS. The red warning below appears in Chrome.
We launched the Chrome Cleanup Tool, a one-shot UwS removal tool that has helped clean more than 40 million devices. We shed more light on a common symptom of UwS—unwanted ad injectors. We outlined how they make money and launched a new filter in DoubleClick Bid Manager that removes impressions generated by unwanted ad injectors before bids are made.
We started using UwS as a signal in search to reduce the likelihood that sites with UwS would appear in search results.
We started disabling Google ads that lead to sites with UwS downloads.
It’s still early, but these changes have already begun to move the needle.
UwS-related Chrome user complaints have fallen. Last year, before we rolled-out our new policies, these were 40% of total complaints and now they’re 20%.
We’re now showing more than 5 million Safe Browsing warnings per day on Chrome related to UwS to ensure users are aware of a site’s potential risks.
We helped more than 14 million users remove over 190 deceptive Chrome extensions from their devices.
We reduced the number of UwS warnings that users see via AdWords by 95%, compared to last year. Even prior to last year, less than 1% of UwS downloads were due to AdWords.
However, there is still a long way to go. 20% of all feedback from Chrome users is related to UwS and we believe 1 in 10 Chrome users have hijacked settings or unwanted ad injectors on their machines. We expect users of other browsers continue to suffer from similar issues; there is lots of work still to be done.
Looking ahead: broad industry participation is essential
Given the complexity of the UwS ecosystem, the involvement of players across the industry is key to making meaningful progress in this fight. This chain is only as strong as its weakest links: everyone must work to develop and enforce strict, clear policies related to major sources of UwS.
If we’re able, as an industry, to enforce these policies, then everyone will be able to provide better experiences for their users. With this in mind, we’re very pleased to see that the FTC recently warned consumers about UwS and characterizes UwS as a form of malware. This is an important step toward uniting the online community and focusing good actors on the common goal of eliminating UwS.
We’re still in the earliest stages of the fight against UwS, but we’re moving in the right direction. We’ll continue our efforts to protect users from UwS and work across the industry to eliminate these bad practices.
The new Authenticator also comes with a developer preview of support for NFC Security Key, based on the FIDO Universal 2nd Factor (U2F) protocol via NFC. Play Store will prompt for the NFC permission before you install this version of Authenticator.
Developers who want to learn more about U2F can refer to FIDO's specifications. Additionally, you can try it out at https://u2fdemo.appspot.com. Note that you'll need an Android device running the latest versions of Google Chrome and Authenticator and also a Security Key with NFC support.
Social engineering—and phishing in particular—requires different protection; we need to keep an up-to-date list of bad sites on the device to make sure we can warn people before they browse into a trap. Providing this protection on a mobile device is much more difficult than on a desktop system, in no small part because we have to make sure that list doesn’t get stale, yet:
Mobile data costs money for most users around the world. Data size matters a lot.
Mobile data speeds are slower than Wi-Fi in much of the world. Data size matters a lot.
Cellular connectivity quality is much more uneven, so getting the right data to the device quickly is critically important. Data size matters a lot.
Maximum Protection Per Bit
Bytes are big: our mantra is that every single bit that Safe Browsing sends a mobile device must improve protection. Network bandwidth and battery are the scarcest resources on a mobile device, so we had to carefully rethink how to best protect mobile users. Some social engineering attacks only happen in certain parts of the world, so we only send information that protects devices in the geographic regions they’re in.
We also make sure that we send information about the riskiest sites first: if we can only get a very short update through, as is often the case on lower-speed networks in emerging economies, the update really has to count. We also worked with Google’s compression team to make the little data that we do send as small as possible.
Together with the Android Security team, we made the software on the device extra stingy with memory and processor use, and careful about minimizing network traffic. All of these details matter to us; we must not waste our users’ data plans, or a single moment of their battery life.
More Mobile
We hunt badness on the Internet so that you don’t discover it the hard way, and our protection should never be an undue burden on your networking costs or your device’s battery. As more of the world relies on the mobile web, we want to make sure you’re as safe as can be, as efficiently as possible.
This page tries to trick you into downloading and executing malware or unwanted software. It uses Chrome’s logo and name to confuse you into believing the site is operated by Google. Content like this may include an inconspicuous legal disclaimer that states it is not affiliated with Google. This does not change the deceptive nature of this content—as always, use caution when downloading files from the web.
This is a fake tech phone support page. This page mimics a warning and may trick you into calling a third-party company that pretends to be Google or some other trusted entity, but charges a fee for support. (Chrome does not offer paid remote support).
This is a fake Google login page. It might trick you into disclosing your account login credentials. Other phishing sites like this could trick you into giving up other personal information such as credit card information. Phishing sites may look exactly like the real site—so be sure to look at the address bar to check that the URL is correct, and also check to see that the website begins with https://. See more information here.
If we identify that a web page contains social engineering content, Chrome will warn you by displaying the following warning:
(If you believe Safe Browsing has classified a web page in error, please report it here.)
We'll continue to improve Google's Safe Browsing protection to help more people stay safer online. Check out the Safe Browsing Transparency Report to find out more.
Newer security challenges and how we can address them
Our study identified several new security challenges as well.
First, we found regions of the Internet actively preventing message encryption by tampering with requests to initiate SSL connections. To mitigate this attack, we are working closely with partners through the industry association M3AAWG to strengthen “opportunistic TLS” using technologies that we pioneered with Chrome to protect websites against interception.
Second, we uncovered malicious DNS servers publishing bogus routing information to email servers looking for Gmail. These nefarious servers are like telephone directories that intentionally list misleading phone numbers for a given name. While this type of attack is rare, it’s very concerning as it could allow attackers to censor or alter messages before they are relayed to the email recipient.
While these threats do not affect Gmail to Gmail communication, they may affect messaging between providers. To notify our users of potential dangers, we are developing in-product warnings for Gmail users that will display when they receive a message through a non-encrypted connection. These warnings will begin to roll-out in the coming months.
All email services—Gmail included—depend on the trust of their users. Partnering with top researchers helps us make the email ecosystem as a whole safer and more secure for everyone. Security threats won’t disappear, but studies like these enable providers across the industry to fight them with better, more powerful protections today and going forward.
[This work was made possible thanks to the contribution of many Googlers including Vijay Eranti, Kurt Thomas, John Rae-Grant, and Mark Risher.]
Following the implementation of these corrective steps, we expect Symantec to undergo a Point-in-time Readiness Assessment and a third-party security audit. The point-in-time assessment will establish Symantec’s conformance to each of these standards:
WebTrust Principles and Criteria for Certification Authorities
WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security
WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL
The third-party security audit must assess:
The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool.
That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key.
That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS.
We may take further action as additional information becomes available to us.
If a favorite website shows up as “dangerous,” it’s often due to user-uploaded bad content or a temporary malware infection. The Site Status will return to normal once the webmaster has cleaned up the website. To help speed up this process, we automatically give the webmaster a heads-up about the problem via Search Console; if you use Google Analytics, we’ll also warn you there if your site has malware on it. (Webmasters, check the help center to learn how to remove malware from your websites.)
We’re constantly working to keep users safe and informed online. Visit the updated Site Status section in the Transparency Report to experience it yourself.
This change is a better visual indication of the security state of the page relative to HTTP.
Chrome users will have fewer security states to learn.
(Not) Warning About Mixed Content
This change will mainly affect HTTPS pages that contain certain mixed content, such as HTTP images.
Site operators face a dilemma: Switching an HTTP site to HTTPS can initially result in mixed content, which is undesirable in the long term but important for debugging the migration. During this process the site may not be fully secured, but it will usually not be less secure than before.
Removing the yellow “caution triangle” badge means that most users will not perceive a warning on mixed content pages during such a migration. We hope that this will encourage site operators to switch to HTTPS sooner rather than later.
Fewer Security States
This change will reduce the number of page security states in Chrome from four to three.
We have to strike a balance: representing the security state of a webpage as accurately as possible, while making sure users are not overwhelmed with too many possible states and details. We’ve come to understand that our yellow “caution triangle” badge can be confusing when compared to the HTTP page icon, and we believe that it is better not to emphasize the difference in security between these two states to most users. For developers and other interested users, it will still be possible to tell the difference by checking whether the URL begins with “https://”.
In the long term, we hope that most sites on the internet will become secure, and we plan to reduce the icon to just two states: secure and not secure. The change announced in this post is a small step in that direction.
Once enabled, your blog will become accessible over both HTTP and HTTPS connections. Blogspot authors should be aware that if they choose to encrypt at this time, some of the current functionality of their blog may not work over HTTPS. This can be a result of template, gadgets, and blog post content, and is often caused by mixed content errors, some of which may be fixable by the author themselves.
For the Blogspot authors who try this out - we’re interested to hear your feedback while we continue to improve this feature and its capabilities! For more information, visit our Help Center.
In aggregate, the problem may appear intractable to stop. However, if we view this scenario in an economic light, then increasing the cost of fake accounts, phone numbers, or compromised websites cuts into the profitability of abuse. In the end, abuse propped up by cost-ineffective resources will crumble. Collaborating to better understand the underground
Given the complex underbelly of abuse, we pulled together experts from industry and academia to build a systematic understanding of how criminals operate. Our previous example represents just one configuration of a value chain. In our example, revenue originates solely from victims buying counterfeit products. Criminals could adapt this strategy to scam users into paying for fake anti-virus, defraud advertisers via clickbots, or liquidate a victim’s banking assets. Regardless of the composition, we argue there is always a profit center through which victims transfer new capital into the underground. These schemes form a spectrum between selling products to unwitting victims to outright theft. A medley of alternatives such as dating scams, call-center scams, premium SMS fraud, DDoS extortion, or even stealing and re-selling gaming assets all fall within this spectrum and ultimately derive a payout from victims outside the underground.
These profit centers are in turn propped up by an ecosystem of support infrastructure that can be configured arbitrarily by criminals per their requirements. This infrastructure includes compromised hosts, human labor, networking and hosting, and accounts and engagement—all available for a fee. For example, 1,000 Google accounts cost on the order of $170, compared to CAPTCHAs which cost $1 per thousand. These costs reflect socio-economic factors as well as the impact of technical, legal, and law enforcement interventions on the availability of resources. Redefining the abuse arms race
Client and server-side security has dominated industry’s response to digital abuse over the last decade. The spectrum of solutions—automated software updates, personal anti-virus, network packet scanners, firewalls, spam filters, password managers, and two-factor authentication to name a few—all attempt to reduce the attack surface that criminals can penetrate.
While these safeguards have significantly improved user security, they create an arms race: criminals adapt or find the subset of systems that remain vulnerable and resume operation. To overcome this reactive defense cycle, we are improving our approach to abuse fighting to also strike at the support infrastructure, financial centers, and actors that incentivize abuse. By exploring the value chain required to bulk register accounts, we were able to make Google accounts 30–40% more expensive on the black market.
In order to make testing as easy as possible we have set up https://cert-test.sandbox.google.com, which requires points 1–3 to be met in order to make a successful connection. Thus, if your TLS client can’t connect to that host then you need to update your libraries or configuration.
No longer serving a cross-sign to Equifax
At the moment the certificate chains that Google properties serve most often include a cross-sign from our CA, GeoTrust, to our previous CA, Equifax. This allows clients that only trust our previous CA to continue to function. However, this cross-sign is only a transitional workaround for such clients and we will be removing it in the future. Clients that include our required set of root CAs (at https://pki.google.com/roots.pem) will not be affected, but any that don’t include the needed GeoTrust root may stop working.
Not only are they intrusive, but people are often tricked into installing them in the first place, via deceptive advertising, or software “bundles.” Ad injection can also be a security risk, as the recent “Superfish” incident showed.
Ad injectors are problematic for advertisers and publishers as well. Advertisers often don’t know their ads are being injected, which means they don’t have any idea where their ads are running. Publishers, meanwhile, aren’t being compensated for these ads, and more importantly, they unknowingly may be putting their visitors in harm’s way, via spam or malware in the injected ads.
Removing injected inventory from advertising
Earlier this quarter, we launched an automated filter on DoubleClick Bid Manager to prevent advertisers from buying injected ads across the web. This new system detects ad injection and proactively creates a blacklist that prevents our systems from bidding on injected inventory. Advertisers and agencies using our platforms are already protected. No adjustments are needed. No settings to change.
We currently blacklist 1.4% of the inventory accessed by DoubleClick Bid Manager across exchanges. However, we’ve found this percentage varies widely by provider. Below is a breakdown showing the filtered percentages across some of the largest exchanges:
We’ve always enforced policiesagainst the sale of injected inventory on our ads platforms, including the DoubleClick Ad Exchange. Now advertisers using DoubleClick Bid Manager can avoid injected inventory across the web.
No more injected ads?
We don’t expect the steps we’ve outlined above to solve the problem overnight, but we hope others across the industry take action to cut ad injectors out of advertising. With the tangle of different businesses involved—knowingly, or unknowingly—in the ad injector ecosystem, progress will only be made if we all work together. We strongly encourage all members of the ads ecosystem to review their policies and practices and take actions to tackle this issue.
USENIX Enigma is a new conference focused on security, privacy and electronic crime through the lens of emerging threats and novel attacks. The goal of this conference is to help industry, academic, and public-sector practitioners better understand the threat landscape. Enigma will have a single track of 30-minute talks that are curated by a panel of experts, featuring strong technical content with practical applications to current and emerging threats.
Google is excited to both sponsor and help USENIX build Enigma, since we share many of its core principles: transparency, openness, and cutting-edge security research. Furthermore, we are proud to provide Enigma with with engineering and design support, as well as volunteer participation in program and steering committees.
The first instantiation of Enigma will be held January 25-27 in San Francisco. You can sign up for more information about the conference or propose a talk through the official conference site at http://enigma.usenix.org
Clearly, careful password management is a priority for both groups. But, they differ on their approaches.
Security experts rely heavily on password managers, services that store and protect all of a user’s passwords in one place. Experts reported using password managers, for at least some of their accounts, three-times more frequently than non-experts.
As one expert said, “Password managers change the whole calculus because they make it possible to have both strong and unique passwords.”
On the other hand, only 24% of non-experts reported using password managers for at least some of their accounts, compared to 73% of experts. Our findings suggested this was due to lack of education about the benefits of password managers and/or a perceived lack of trust in these programs. “I try to remember my passwords because no one can hack my mind,” one non-expert told us.
Key differences: software updates and antivirus software
Despite some overlap, experts’ and non-experts’ top answers were remarkably different.
35% of experts and only 2% of non-experts said that installing software updates was one of their top security practices. Experts recognize the benefits of updates—“Patch, patch, patch,” said one expert—while non-experts not only aren’t clear on them, but are concerned about the potential risks of software updates. A non-expert told us: “I don’t know if updating software is always safe. What [if] you download malicious software?” and “Automatic software updates are not safe in my opinion, since it can be abused to update malicious content.”
Meanwhile, 42% of non-experts vs. only 7% of experts said that running antivirus software was one of the top three three things they do to stay safe online. Experts acknowledged the benefits of antivirus software, but expressed concern that it might give users a false sense of security since it’s not a bulletproof solution.
More broadly, our findings highlight fundamental misunderstandings about basic online security practices. Software updates, for example, are the seatbelts of online security; they make you safer, period. And yet, many non-experts not only overlook these as a best practice, but also mistakenly worry that software updates are a security risk.
No practice on either list—expert or non-expert—makes users less secure. But, there is clearly room to improve how security best practices are prioritized and communicated to the vast majority of (non expert) users. We’re looking forward to tackling that challenge.
Two examples of bad data-center traffic There are two distinct types of invalid data-center traffic: where the intent is malicious and where the impact on advertisers is accidental. In this section we consider two interesting examples where we’ve observed traffic that was likely generated with malicious intent. Publishers use many different strategies to increase the traffic to their sites. Unfortunately, some are willing to use any means necessary to do so. In our investigations we’ve seen instances where publishers have been running software tools in data centers to intentionally mislead advertisers with fake impressions and fake clicks. First example UrlSpirit is just one example of software that some unscrupulous publishers have been using to collaboratively drive automated traffic to their websites. Participating publishers install the UrlSpirit application on Windows machines and they each submit up to three URLs through the application’s interface. Submitted URLs are then distributed to other installed instances of the application, where Internet Explorer is used to automatically visit the list of target URLs. Publishers who have not installed the application can also leverage the network of installations by paying a fee. At the end of May more than 82% of the UrlSpirit installations were being run on machines in data centers. There were more than 6,500 data-center installations of UrlSpirit, with each data-center installation running in a separate virtual machine. In aggregate, the data-center installations of UrlSpirit were generating a monthly rate of at least half a billion ad requests— an average of 2,500 fraudulent ad requests per installation per day. Second example HitLeap is another example of software that some publishers are using to collaboratively drive automated traffic to their websites. The software also runs on Windows machines, and each instance uses the Chromium Embedded Framework to automatically browse the websites of participating publishers—rather than using Internet Explorer. Before publishers can use the network of installations to drive traffic to their websites, they need browsing minutes. Participating publishers earn browsing minutes by running the application on their computers. Alternatively, they can simply buy browsing minutes—with bundles starting at $9 for 10,000 minutes or up to 1,000,000 minutes for $625. Publishers can specify as many target URLs as they like. The number of visits they receive from the network of installations is a function of how long they want the network of bots to spend on their sites. For example, ten browsing minutes will get a publisher five visits if the publisher requests two-minute visit durations. In mid-June, at least 4,800 HitLeap installations were being run in virtual machines in data centers, with a unique IP associated with each HitLeap installation. The data-center installations of HitLeap made up 16% of the total HitLeap network, which was substantially larger than the UrlSpirit network. In aggregate, the data-center installations of HitLeap were generating a monthly rate of at least a billion fraudulent ad requests—or an average of 1,600 ad requests per installation per day.
Not only were these publishers collectively responsible for billions of automated ad requests, but their websites were also often extremely deceptive. For example, of the top ten webpages visited by HitLeap bots in June, nine of these included hidden ad slots -- meaning that not only was the traffic fake, but the ads couldn’t have been seen even if they had been legitimate human visitors. http://vedgre.com/7/gg.html is illustrative of these nine webpages with hidden ad slots. The webpage has no visible content other than a single 300×250px ad. This visible ad is actually in a 300×250px iframe that includes two ads, the second of which is hidden. Additionally, there are also twenty-seven 0×0px hidden iframes on this page with each hidden iframe including two ad slots. In total there are fifty-five hidden ads on this page and one visible ad. Finally, the ads served on http://vedgre.com/7/gg.html appear to advertisers as though they have been served on legitimate websites like indiatimes.com, scotsman.com, autotrader.co.uk, allrecipes.com, dictionary.com and nypost.com, because the tags used on http://vedgre.com/7/gg.html to request the ad creatives have been deliberately spoofed. An example of collateral damage Unlike the traffic described above, there is also automated data-center traffic that impacts advertising campaigns but that hasn’t been generated for malicious purposes. An interesting example of this is an advertising competitive intelligence company that is generating a large volume of undeclared non-human traffic. This company uses bots to scrape the web to find out which ad creatives are being served on which websites and at what scale. The company’s scrapers also click ad creatives to analyse the landing page destinations. To provide its clients with the most accurate possible intelligence, this company’s scrapers operate at extraordinary scale and they also do so without including bot identifiers in their User-Agent strings. While the aim of this company is not to cause advertisers to pay for fake traffic, the company’s scrapers do waste advertiser spend. They not only generate non-human impressions; they also distort the metrics that advertisers use to evaluate campaign performance—in particular, click metrics. Looking at the data across DoubleClick Campaign Manager this company’s scrapers were responsible for 65% of the automated data-center clicks recorded in the month of May. Going forward Google has always invested to prevent this and other types of invalid traffic from entering our ad platforms. By contributing our data-center blacklist to TAG, we hope to help others in the industry protect themselves. We’re excited by the collaborative spirit we’ve seen working with other industry leaders on this initiative. This is an important, early step toward tackling fraudulent and illegitimate inventory across the industry and we look forward to sharing more in the future. By pooling our collective efforts and working with industry bodies, we can create strong defenses against those looking to take advantage of our ecosystem. We look forward to working with the TAG Anti-fraud working group to turn this pilot program into an industry-wide tool.
We’re committed to working with BIS to make sure that both white hat security researchers’ interests and Google users’ interests are front of mind. The proposed BIS rule for public comment is available here, and comments can also be sent directly to [email protected]. If BIS publishes another proposed rule on intrusion software, we’ll make sure to come back and update this blog post with details.
Follow