Greetings from sky bar of Airbus A330! Shortly after I boarded my favourite airline, I couldn’t help but notice the crew member sneak in something along the lines of, “If you can’t find the page that lets you connect to Wi-Fi, just go to purple.com and you’ll get there,” during the safety announcement. I did not, at the time know if this was an official branding strategy employed by Virgin or something that the cheeky crew manager made up in the air. Suffice to say, the technical gears in my head started turning rapidly.

It’s clever.

After all purple is Virgin Atlantic’s theme colour, as abundantly evident from cabin décor and colour scheme. But as always, I’m here to help you understand the technical workings behind the scenes that make “claiming” purple.com at 35,000 feet possible.

In real life, the purple.com domain is owned by mattress giant Purple® and is actively used by them. On Earth, visiting purple.com would lead you to the mattress retailer’s website. This also becomes clear right after you pay for Gogo In-flight Wi-Fi and retry visiting purple.com in your browser. That’s when you’ll get to the mattress seller’s website instead.

But that should make you wonder, how could purple.com be owned by Virgin Atlantic, Gogo Inflight Wi-Fi and the mattress seller all at the same time? This is where local domains come into play.

Local domains or hostnames, in a certain context, make it possible for network administrators to make any domain up in the air (pun) and redirect it to an intranet website of their choice, such as a Captive Portal. That’s the “sign-on to Wi-Fi” portal typically presented by hotspots until you accept their terms of service or if applicable, pay the charges. Whether such a domain exists on the gigantic World Wide Web WWW or not, has no relevance. That means a network admin could make anything up … localhost, axsharma, ax.wifi, inflight.com, purple.com, virginwifi.go… whether these domains exist in reality — on the internet or not isn’t a prerequisite.

Anyone connecting to the network through you — your routing devices or access points, will be redirected to the location of your choice when they visit these locally setup domains. In some cases, the Wi-Fi access point, also acting as the DNS server, can override the actual IP address of a domain with a different one, thereby redirecting you elsewhere.

Local domains indeed make it possible to host your websites accessible only to a select few members of a dedicated network but not the outside world — the internet. It’s what makes corporate intranet possible!

However, in case of most Wi-Fi hotspots — in-flight or on ground, local domains may not always be at play because visiting virtually any website should redirect you to the in-flight W-Fi purchase portal or “sign-in page,” as long as you haven’t paid charges or accepted terms of service.

Typical workflow implemented by Wi-Fi hotspots (Image credit)

This is also why when connecting to webpages beginning with https — which is nearly all of the pages today, over a public Wi-Fi hotspot, you get a series of SSL errors up until the point you “sign-in to the hotspot” or visit a non-HTTPS website. This happens because of a certificate mismatch. The website you are trying to visit, let’s say, is “https://facebook.com” but the router is persistently redirecting all HTTP/HTTPS traffic to its access point homepage, the SSL certificate of which was issued only for that homepage (e.g. https://airborne.gogoinflight.com).

An example SSL/TLS certificate mismatch errors

Web browsers treat this as a security issue because you are visiting facebook.com but effectively being served a website whose certificate clearly dictates you are on airborne.gogoinflight.com. Browsers see this as an ominous sign of a Man-in-the-Middle (MitM) attack where an attacker has possibly hijacked in-flight routing devices to redirect users to a malicious page instead, although in most cases this isn’t the case.

It can further be confirmed that local domains are not at play here by running a simple DNS lookup. Looking up the IP addresses of purple.com’s DNS servers, returned the same result 

104.20.55.235 

and

104.20.56.235 

both in-flight (whether prior to or post payment) as well as on Earth.

DNS query (nslookup) results for purple.com in-flight, pre or post payment:

DNS query (nslookup) results for purple.com on Earth:

The finding implies local domains aren’t really being used and rather captive portal employed by Gogo In-flight WiFi is redirecting any and all HTTP(S) traffic to its sign-in page, up until the point a payment is made. Had this not been the case and purple.com was officially setup locally by the network admin, we’d get very different DNS results at 35,000 feet and on Earth.

Although fair point to note, more likely than not, the name purple.com or for that matter any domain is merely being used as a catchy, marketing phrase that’s easy to remember for passengers. In actuality, any domain or phrase — even your own name followed by a forward slash, should redirect you to the in-flight Wi-Fi page as you’ve likely observed.

When asked if purple.com had anything to do with strategic branding, Virgin Atlantic’s spokesperson officially responded with:

But for Virgin Atlantic, this is clever marketing generated on the fly by the crew member. At over 35,000 feet you may easily lose track of time left to your destination or what your choice of red wine was, but purple.com stays fresh in your memory for long.

© 2019. Akshay “Ax” Sharma (Twitter). All Rights Reserved.