WirelessPhreak.com

Everybody has heard of secret menu items at Disneyland, and almost every eatery has at least one.  So myself and some friends have started a living document to track and rate the secret menu items we run across.

Captive portals have become synonymous with guest Wi-Fi in enterprise environments. From Starbucks to your doctor's office people expect free and easy to use Wi-Fi,  but what was once easy to do is getting more difficult. Browser security is always improving which has made the goal of HTTPS redirects even more difficult. Captive portal redirection for users going to HTTPS websites has always created SSL related errors -- this has helped create a cry wolf scenario when it comes to HTTPS redirection errors. This error rich environment has helped HSTS errors fly under the radar.

At a high level HSTS (HTTP Strict Transport Security) is a policy that, when enabled, forces a browser to use an HTTPS connection over a HTTP and allows for the SSL certificate to be cached on the browser for a predetermined length of time. With HSTS enabled, clients are protected from protocol downgrading, man in the middle attacks, and cookie hijacking. Most modern browsers (Google Chrome, Mozilla Firefox, Microsoft Edge) come preloaded with a list of sites supporting STS (Strict Transport Security).  Along with the pre-configured list built into browsers, developers can take it upon themselves to enable this policy on their sites. Once enabled a timeout will be sent with the HTTPS header that contains a HSTS TTL “Strict-Transport-Security: max-age=31536000”. The certificate received from the site will be honored until the timeout expires. Future attempts to access the site will reference the certificate and,  if the certificate does not match, the browser will not allow the connection to site to be established.

For a more in depth HSTS description check out Troy Hunt's post Understanding HSTS.

So how does HSTS break captive portals?  HSTS enforces the use of HTTPS. It enforces this using two methods that where mentioned earlier the HSTS header or STS preload lists in the browser. When a user connects to a captive portal and launches their browser, normally the wireless controller would intercept their Internet request and a redirect is sent back to the client. This redirect to the captive portal will obviously be a different CN than their original request so, many times, this creates an SSL error. Many users have become numb; accepting the error and continuing to the portal. But HSTS is a little different.

Just got back from Disneyland and with rumors of guest Wifi in the park I thought I would do a little war walking. I didn't bring a sophisticated set up, just an android phone running Wigle connected to an external battery.  Also I didn't make a point to map the entire park so this is just a sample of the first half of the first day.

As of 4/25/2017 it does not appear that Disney has rolled out park wide guest access, but the infrastructure is impressive. Again this is a very small data sample, but perhaps the 161 networks that where not broadcasting an SSID could be the pre deployed guest network. Also it looked to  be a Cisco wireless deployment based on the mac addresses of the radios.

Guest network or not Disneyland has an impressive wireless infrastructure, and providing guest wifi for a property as large and as densely populated as Disneyland will be an impressive feat of engineering.


SSID                                 # of APs        Icon
WLAN-TWDC                 198              
no  SSID                           161               
ShowNET-TWDC            33                
Disney Guest                    13                
Internet-TWDC                10                
Disneyland_Resort           6                  


The captive portal for Internet-TWDC