Google’s push to encrypt ads will improve security, but won’t kill malicious advertising
By Lucian Constantin
Google plans to serve most of its ads over encrypted HTTPS connections by the end of June, a move that will protect against some ad hijacking attacks and will encourage website owners to enable encryption on their Web properties.
However, malicious advertising attacks that direct users to Web-based exploits will still be possible and, because of the new encryption, it will actually be harder for security researchers to pinpoint their source.
Last year, Google announced that it will give more weight to HTTPS-enabled websites in search rankings in order to encourage the adoption of encryption across the Web. HTTPS (HTTP Secure) allows Web communication over a channel encrypted with the TLS (Transport Layer Security) protocol.
One of its main benefits is that it prevents the traffic from being read or modified by someone in a position to intercept it—hackers in control of a router or prowling inside an insecure wireless network, rogue ISP employees, or a government agency spying on the Internet backbone.
A big problem webmasters have with implementing HTTPS is not the cost of buying digital certificates, but the fact that their websites load resources—primarily advertisements—from third parties that don’t serve them over HTTPS. Loading non-encrypted resources into HTTPS websites will lead to mixed content warnings in browsers and cancels the security benefits of enabling HTTPS in the first place.
In this context, Google’s efforts to start encrypting ad traffic will make transitioning to HTTPS easier for many websites, therefore increasing overall privacy and security on the Web.
By June 30 of this year, Google will encrypt “the vast majority” of mobile, video, and desktop display ads served to the Google Display Network, AdMob, and DoubleClick publishers, the company said Friday in a blog post. By this date, advertisers using any of Google’s buying platforms, including AdWords and DoubleClick, will also be able to serve “HTTPS-encrypted display ads to all HTTPS-enabled inventory.”
Encrypting advertising traffic for mobile devices will protect against some man-in-the-middle attacks that researchers have warned about for years, where attackers could inject rogue code into advertising traffic to abuse the permissions of the apps displaying the ads.
It will also protect against ad injection attacks done at the network layer, for example, through compromised routers. However, it won’t prevent locally installed adware programs like Superfish or malware threats from displaying rogue ads on HTTPS websites opened in the local browser.
Of course, in order for encryption to have a truly large scale impact, the entire online advertising industry needs to join in the effort.
According to the Interactive Advertising Bureau (IAB), a large advertising industry association, almost 80 percent of its members’ ad delivery platforms support HTTPS. However, support and actual use are two different things. For ads to be delivered to a website over HTTPS, it’s not enough for the site’s primary ad server to support encryption. There’s a lot that needs to happen in the complicated advertising supply chain as well.
“That ad server will sometimes need to include tags from brand safety, audience and viewability measurement, and other tools—all of which also need to support encryption,” explained IAB’s Director of Technical Standards Brendan Riordan-Butterworth in a blog post in March.
The publisher’s ad server will often direct to one of several agency ad servers, each of those will also need to serve over HTTPS. “Each agency ad server also may include a variety of beacons or tags, depending on how the deal was set up, all of which similarly need to have encrypted versions available,” he wrote.
And simply encrypting the traffic won’t stop malvertising attacks, which pose the biggest risk to users. These are attacks where criminals manage to push rogue ads onto an advertising network so that when those ads are displayed on popular websites they redirect users’ browsers to servers hosting exploits. If successful, those exploits install malware programs on their computers.
Google had to deal with at least two malvertising attacks on its DoubleClick network over the past two weeks. In one of those cases, researchers from Dutch security firm Fox-IT tracked the malicious ads to a Bulgarian reseller of Google advertising services whose systems they believe were compromised.
Even if that reseller would have served ads over HTTPS, it wouldn’t have prevented attackers with access to its ad platform from pushing malicious advertisements onto Google’s network, said Fox-IT researcher Maarten van Dantzig Monday. Moreover, if the ad traffic had been encrypted, Fox-IT wouldn’t have been able to pinpoint the offending ad campaign and track it down to the Bulgarian company, he said.
While the researcher agreed that Google’s decision to encrypt ad traffic is generally good for everyone’s security and privacy—the whole Web should be encrypted, he said—the move does have drawbacks; for one, it decreases the visibility of network defenders.
For example, a network security appliance won’t be able to detect and block malicious code hidden inside encrypted advertising traffic unless the device is configured to also act as an HTTPS interception proxy—decrypting and re-encrypting traffic with a self-signed CA certificate deployed on all endpoints. Many companies don’t yet have such a set-up.
Malicious advertisements typically redirect browsers to Web-based exploits hosted on non-HTTPS servers, so network appliances might actually be able to detect and block the exploits themselves. However, researchers or network security analysts investigating such incidents will not be able to see which specific ad triggered it.
With less visibility for security researchers, advertising networks will need to identify the rogue ads on their own, van Dantzig said.
He wasn’t sure if many of them are ready to do that.
When you purchase through links in our articles, we may earn a small commission. This doesn't affect our editorial independence.