WirelessPhreak.com

I like to travel, f*ck with technology, and partake in the occasional tropical drink.
I am also a co-host on The NBD Show podcast.
Follow Me
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.


Because HSTS already knows the website should be using HTTPS the browser issues an internal HTTP 307 redirect redirecting the traffic to HTTPS even before it attempts to connect to the server. Once it connects to the server it attempts to validate the HSTS valid certificate. In the case of a redirection the captive portal would not be insuring the same HTTPS HSTS validated certificates. When this happens the browser will assume something nefarious is going on and not allow the redirection to occur. I know one vendor has a bug report filed for this issue - even though its not really a bug - and I don't know if its a fix the wireless vendors can provide.

Bottom line for users connected to a captive portal today:
  • If the user visits an HTTP site, they are immediately redirected to the captive portal. This works regardless of what browser they are using
  • If the user visits an HTTPS site that does not use HSTS, they receive a warning. If they click "Continue" they are redirected to the captive portal. This works regardless of browser
  • If the user visits an HTTPS site that does use HSTS and they are using the browser that supports HSTS they are dead-ended. The only way to get redirected to the captive portal is to visit a different site. Many people have https://www.google.com or Facebook set as their homepage. Both of these sites use HSTS so this might confuse some users.

This issue of not being redirected to a captive portal affects every wireless vendor. As more and more sites use HSTS, getting a proper redirect becomes harder. Hopefully the wireless vendors are sitting on the working group for this new standard and are pushing hard to get it ratified. 

In the long run, if something is not done, enterprises will quit using captive portals if it becomes really tough to get a proper redirect. But for now, being forced to use captive portals, I have not seen a sure fire technical way of getting around the issue.  But you can get around the HSTS errors through communication and policy. 

For example:
I am considering turning off HTTPS redirection all together. What this does is create a predictable environment for the users and the system admins. By not redirecting HTTPS you take the confusion of redirection issues based on SSL certificates, HSTS, or any new security the browsers builds in and level the playing field. Then in the case of using a sponsored portal, the email notification that is sent to visitor and/or person being visited can include the verbiage, "If you are not redirected to the guest portal please type a non secured HTTP website into your browser".  




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.

Lastly Disney if you see this post I have a suggestion for the guest network SSID. 
"Be Our Guest"

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



This is the 2.0 version of my previous Defcon Prep Guide. Every year more people ask me about attending Defcon for the first time. Many are intimidated or not sure if they should attend. I hope to address their concerns and sway them toward checking out Defcon.

Should I Attend: This is probably the first and most frequent question I get about Defcon. There is a lot of lore and hype around Defcon much of which is earned and deserved, but you don't have to be a 1137 black hat hacker to go to Defcon. Defcon has something for everyone, and I mean everyone. Defcon is usually broke up into 4 tracks that are loosely themed and diverse. So diverse you can generally find talks that interest you in any of the tracks. Check out this link to Defcon 24's schedule to get an idea of what the talks are about.

But the talks are just a small portion of a much bigger convention. As a first time attendee, I would recommend spending most of your time in the different villages, and competition areas. These are smaller convention within the convention where people who are interested in anything from Ham radios, to social engineering, to car hacking can spend the entire day hanging out with people who share their interests.  Here is a link to Defcon 24's Village Talks.

It may seem overwhelming but just find something that interests you and don't try to do everything.  Oh ya and drink some beer, there will be a lot of it.

When is Defcon: Its normally held towards the end of July or beginning of August. It's a good idea to get there a day early, usually Thursday, to buy SWAG and get your badge because it gets super busy the day of.

ProTip: You will want to go down Thursday morning or stay up parting Wednesday night to get your badge.  People start lining up around 4:00am for the Convention passes.

How Much is Defcon:  The registration fee goes up a little every year, and they will post the fee as we get closer to the Con. Most everything at Defcon is cash only including the ticket, and for the love of god don't use an ATM any where near the convention.
  • Registration: $230 to $250 (just a guess)
  • Hotel: Defcon room rates differ depending when you book, but Defcon usually negotiates a good price.

Where to Stay: Staying at the hosting hotel is a must.  It's nice to just head up to your room between talks, and attending the late night festivities are a breeze since you only have stumble to the elevators. Reserve your rooms early for Defcon, the hosting hotel sells out quickly. 

Added bonus; If you stay at hosting hotels Defcon will stream the talks and schedules to the hotel rooms. This is not always guaranteed especially when they move to a new venue, but they usually work it out.  

What to Bring:  A few essentials I bring to Vegas.
  • Snacks because eating at the CON can get kinda pricey, plus a lot people save the money for drinking.
  • Buy a cheap throw away cooler for refreshments and ICE in the room.
  • A laptop "AT YOUR OWN RISK" If you bring your laptop do not bring it to the Con, leave it in your room and even then disable your wifi, bluetooth, and do not use the hotel Internet.  Defcon's network, including the hotels, have been deemed the most hostile network in the world.  Even the cellular network is hostile and usually sucks anyway, "Thanks Ninja Tel". That being said, if you have a fresh wiped laptop and you want to partake in the festivities bring it just don't use it for anything other then hacking, and reformat when you get home.
  • Cell Phone, if you have an old school flip phone bring it.  If you bring your smart phone make sure to turn off the radios, i.e. wifi, bluetooth, etc. Nothing is safe.
  • Aspirin for obvious reasons
  • Your finest hacker tees, there kinda a big thing, and a comfortable pair of shoes.  You will be standing in some lines, imagine a Disneyland for hackers...
Useful Links:

Twitter to Follow:
  • @defcon
  • @DEFCON_NOC
  • @wallofsheep
  • @DC_HHV
  • @toool
  • @dcib

Hope to see you there, you can hit me up at @hackercult on twitter and the convention


So the congress and senate decided to look out for its constituents and protect the privacy of the people who put them in office.  In the immortal words of Borat, "NOT"! The repealing of the FCC's Broadband Privacy Rules only benefits the internet providers. It actually provides a substantial revenue stream for big business, Comcast, Time Warner, ATT, .etc. that did not exist before. One of the analogies used to justify the vote was, "it evens the playing field", what they meant was because the Googles, Yahoos, and Facebooks, can use your information to deliver targeted ads why can't we (the ISPs) do it?

Well let's start with the reality.  Today Google does deliver targeted ads from information they gather through browsing history, email, etc. For most this is a trade off for service. Google can provide the most popular free email client and web browser in the world because of the advertising they sell. When you sign up for Google or Yahoo, you are the product.  That is a well understood concept, and most people are willing to trade their information for free services. This is where the level playing filled analogy breaks down. ISPs such as Comcast or Time Warner charge for their services, and in most cases a lot. Its true they have been monitoring your traffic, just ask anyone who has received a cease and desist letter after a torrent download. Now they can act on that information, they can start injecting adds into your web browsing, selling your non identifiable browsing data, and collecting everything you do online.

So what impact does that have ultimately on the users? In the short term for the average user maybe not a lot, but these are different times. We should trust our ISP to be responsible for our privacy, but with the collection of this data it makes them a rich target not only for hackers, but the government. Think about a world where the government in conjunction with the internet providers have identified every person using the internet. With their browsing data is able to conclude their illnesses, banking information, relatives, sexuality, hobbies - I challenge you to think about your life and what if any part you have never searched on the internet or uploaded to social media.

That is an extreme example, I hope, but very plausible. Our privacy and freedom of speech is a cornerstone of America and to just give it up to benefit- lets face it- horrible companies make more money seems like a stupid thing to do.

Check out these links if your interested:
EFF Electronic Frontier Foundation
ACLU American Civil Liberties Union
Bruce Schneier Schneier.com
cloudwards.net

Please check out the EFF's Surveillance Self-Defenense site.  It has a ton of tools and information to help you understand and what to do about your online privacy.  Of course it was original put together to aide individuals in repressive regimes, but maybe thats where we are at.
https://ssd.eff.org/en

If your a techy and do it your self kind of person, here is a link to Open VPN's AWS guide to deploying your own VPN server in AWS.  If you want to give it a try AWS will give you  free year and OpenVPN includes a free 3 device license with their OpnVPPN Access Server. It was really easy to set up and it will work with PC, Mac, IOS, and Android.
Open VPN Access Server on AWS