Recent Posts

Posts by Topic

see all

Google Pushing HTTPS Further

by Hemant Chaskar on Sep 11, 2014

Implications for Public Facing Wi-Fi Security, Advertising and Analytics

You may have already noticed - Google search has been strictly using HTTPS for some time now. Typically, people do not enter passwords in keyword search and so people probably were not terribly worried about search sites not using HTTPS (Bing still allows HTTP). Nonetheless, Google seems to have taken position in favor of HTTPS. YouTube also allows HTTPS (though HTTP option is also available today). When YouTube page is accessed over HTTPS, videos also stream over HTTPS (a way to check this is funny name option called "Stats for nerds" which shows on right click on YouTube video). One could also say Google is making a point here that HTTPS isn’t necessarily the scalability bottleneck today.

Additionally, just last month, Google disclosed that they will provide (slight for now) SEO rank incentives to HTTPS sites. If this push for HTTPS is maintained by Google and other Internet giants, many sites on the Internet could move to HTTPS in medium term future (news and other type of information distribution sites have the least penetration of HTTPS).

What got me thinking was how HTTPS adoption could impact the public facing Wi-Fi. A few examples come to mind as follows.

Honeypot Security

Honeypots (Wi-Phishing) has always been the security pain point in public facing Wi-Fi. HTTPS helps alleviate that pain point. Not all by itself, but with some support from browsers and devices as described below, the HTTPS migration of the websites will help reduce “man-in-the-middle” security incidents in the public Wi-Fi.

Browser support - If most useful sites move to HTTPS, one can think of a Public Wi-Fi mode in the browser that will allow only HTTPS URLs. In this mode, the browser also needs to block the sessions with certificate validation errors (i.e. not provide the option to continue as browsers do today). These two things combined can enforce strict HTTPS for browsing when connected to the public Wi-Fi. Note that HTTP should not be allowed at all in this mode - even to read news sites - because once it is allowed it opens doors for the man-in-the-middle hacks like SSLStrip and malicious links in HTTP pages served by the man-in-the-middle.

In addition to browsing, people will use Apps when connected to the public Wi-Fi. Apps which do not use secure connection (HTTPS), could be tagged so by Android Market or Apple App Store and blocked in the Public Wi-Fi mode (now a device setting).

Such increased level of security should provide great impetus to public facing Wi-Fi which is already riding the momentum wave.

[Tweet "Google Pushing HTTPS Further by Hemant Chaskar @CHemantC via @AirTight blog"]

Related AirTight Blogs:

In-session Messaging/Advertising

Some solutions have attempted injecting messages or advertisements into the browsing sessions of public Wi-Fi users. I read about a feature called Browser Engage last year on Cisco's Mobility blog. According to this blog post, a built-in proxy server in Cisco MSE intercepts user’s traffic to insert JavaScript into that page. The JavaScript then executes in the browser to insert messages and advertisements in the page being viewed.

Such JavaScript insertion requires proxy to function as “man-in-the-middle” of the session by terminating the user’s HTTP session on one side and interacting with the web server on the user’s behalf on the other side - to fetch the content requested by the user. JavaScript is inserted in the fetched content before forwarding it to the user.

Clearly, such “man-in-the-middle” operation isn’t possible with HTTPS sites (without user seeing the certificate validation error), and hence, increased HTTPS penetration will diminish messages/advertisements injection opportunities in Wi-Fi users’ browsing sessions.

There was also news last week about Comcast attempting ad injection in the home Wi-Fi users' browsing sessions. Such injection isn't possible when user accesses HTTPS URLs.

SSL Interception Proxy - On a related note, enterprise firewalls routinely use SSL Interception Proxy to scan HTTPS pages. This feature however requires firewall's trusted root certificate to be installed in the client browser. The firewall generates certificates for sites browsed by the user on the fly, but under its own certificate authority. This allows the firewall to interject itself as “man-in-the-middle” of the HTTPS session without triggering the certificate validation error.

Do you really believe you have end to end secure connection with your bank when you access your account from the office? Think again.

Anyway, such transparent interception is not feasible in public facing Wi-Fi because of lack of control over the client.

DPI Analytics over In-Store Wi-Fi

Recently, I heard about idea floated by Fortinet which involves being able to analyze brick and mortar shoppers’ browsing sessions over in-store guest Wi-Fi using deep packet inspection (DPI) technology. It seems the use case being that the DPI engine would infer if the user is looking for the same item on e-commerce or competitor site and then react by providing instant coupons.

This requires the DPI engine to be the “man-in-the-middle” of the browsing session. To be precise, it requires the DPI engine to be the reader in the middle of the session, since in this case the pages are not being modified, just read.

If people use Google search to look up the article on the web, the fact that Google search is strict HTTPS, DPI cannot infer the item being searched. The retailers’ websites which will show up in the Google search may not be using HTTPS today (until you go to checkout link), but this could change in near future in a race to higher SEO rank. If people use Amazon App to search for competitive pricing, that App uses HTTPS already (though Amazon website currently does not use HTTPS until you go to checkout, but that could change with SEO incentive for HTTPS). So, DPI based real time analytics over guest Wi-Fi seems to be headed for roadblock with increased HTTPS adoption. There are also additional practical challenges over and above HTTPS such as feasibility of real time machine based interpretation of pages, but that is out of scope for this blog.

Overall, increased HTTPS adoption on the web can bring in some interesting changes in the experience of the public Wi-Fi users and advertisers. Everyone is going to like the increased level of security. And, whether you like or dislike the implications for consumer targeting depends on which side of the debate you are on.

Related Content:

[Tweet "Google Pushing HTTPS Further by Hemant Chaskar @CHemantC via @AirTight blog"]

Topics: Wireless security, Privacy, WiFi Access