Gogo has become a household name by keeping consumers connected at 10,000 feet with the popular Gogo Inflight Internet service. Recently, however, Gogo has been receiving attention and, more specifically, criticism, in the wake of a tweet from Google security engineer Adrienne Porter Felt (@__apf__) to Gogo (@Gogo).
The tweet referenced a screenshot of an untrusted certificate being served with the *.google.com common name when requesting YouTube. Many news outlets quickly picked up on the tweet and fired off harsh articles accusing Gogo of performing an active man-in-the-middle (MiTM) attack to mine data from travelers.
Although we had a lengthy discussion on the topic during a recent
Tripwire Security Slice Podcast, I think there are a few points worth putting down in writing.
First and foremost, I feel it is important to make it clear that despite the alarming “*.google.com” common name on the certificate, Gogo was not necessarily intercepting all encrypted connections or even all encrypted connections to Google. The proper certificate from Google for YouTube has a *.google.com CN along with *.youtube.com and many other domains listed as valid DNS for the certificate.
Immediately upon reading the stories of Gogo performing a MiTM on Google, I knew that they most certainly were not blindly forging certificates for all Google domains, since this would break many mobile applications, including the popular Gmail for Android app. Despite this, I was still compelled to get connected on a recent flight and confirm these suspicions.
Over Twitter, I was able to connect with Adrienne while onboard the flight and confirm that this was also the behavior she observed.
As I discussed back at DefCon 21, a token for one Google service, such as YouTube, is generally sufficient to gain access to other Google services like Gmail and Docs. This means that users who were willing to trust Gogo’s fake certificate while logged into Google services (which apparently includes at least one Google security engineer) could have their accounts compromised if the authentication tokens were logged by a third party. For Gogo’s part, they have stated (and I believe them) that they only had the best intentions in mind.
From what I understand, an entire airplane is sharing a connection many times slower than what most customers have at home or even from their smartphones. Quality of service policies are needed to keep the service usable for paying customers, which is exactly what Gogo has stated as a reason for the SSL inspection. The streamlined, single sign-on functionality operating across Google web properties works against the service, in this case, by making a wider net for attackers to steal valuable authentication tokens.
Generally speaking, many users have been conditioned to accept captive portal pages on public Wi-Fi that intercept any initial SSL requests to present a login page. These systems also will issue their own *.google.com certificates but, for some reason, this detail was lost in most media reports.
If there is a productive discussion to be had around the security model employed by Gogo, it should be about the use of open Wi-Fi networks, rather than restricted access to an encrypted video streaming service. Unfortunately, the use of open networks for wireless Internet providers is the norm, leaving untold numbers of devices configured to automatically connect to networks based on nothing more than a familiar name.
The security industry has tried to educate consumers on the risks of open Wi-Fi, but the lesson has, for the most part, been lost on the general public. Commercial hacking tools like the Pineapple Wi-Fi make it trivial for even non-technical users to begin exploiting these weak configurations to harvest credentials or carry out other attacks. Integration with commercial penetration testing software like Core Impact extends the attack potential even further by allowing automated injection of exploit code into network traffic consumed by laptops and phones.
Until devices become smart enough to accurately distinguish rogue access points from legitimate ones, it is necessary for end-users to be vigilant about their wireless connection profiles if they wish to safeguard their private data. Since open networks will not be going away overnight, this means that security minded consumers must actively add and remove open connection profiles as needed and, of course, turn off Wi-Fi in places where no signal is expected. This approach will work, but it’s unlikely that consumers will adopt this model.
As a security professional, I would much rather see the vendors find a more comprehensive solution. One approach would be to provide the option to use certificate based authentication in place of unprotected networks. While many users will probably never care to establish certificate based trust with wireless providers, the option of certificate validation would at least provide security-minded users with additional confidence that they are connecting to a legitimate access point for the service.
