Hacker News Reader

Comment by repsilat | Hacker News Reader

When I'm on free airport wifi they'll often limit the session to half an hour and then start MITMing your traffic to try to bounce you back out to the sign-in page to agree to the terms and conditions again. When that happens, the redirect won't work if you're trying to browse to an HTTPS URL. Worse, for many sites you can't tell your browser to "just go along with the MITM" because of HSTS.

So in airports I rack my brain for a website that might serve content over HTTP, not HTTPS. Alas, they're getting harder to find, and it's getting harder to keep those airport wifi sessions going. I half considered registering "alwaysinsecure.com" or "alwayshttp.com" so I could reliably find one... Now I'll probably just use qq.com, it's short and easy to remember.

EDIT: Thanks all :-)

View on HN

http://neverssl.com/ is what you're looking for here.

I just use example.com

Interesting. What the prescription here - to simply use http://neverssl.com in order to see if you need to re-authenticate to the captive portal? Is that correct?

That's my interpretation of what http://neverssl.com says. (Did you click-through to read it?)

And http://info.cern.ch/hypertext/WWW/TheProject.html still retains it non-encryptedness

http://http.rip is what I use

This really highlights the problem that we need a proper technical solution for and not hacky traffic interception/redirects!

I also created http://httpforever.com/ for this purpose until such a time that the problem is solved properly.

It's not a technical or even standards setting problem. IIRC there's already a RFC for DHCP announced login webpage. It's business and legal - layer 8 and 9 problems.

Operating system maintainers have added captive portal detection to improve user experience. Hotspot owners often sabotage captive portal detection by whitelisting Apple and Google's CPD URLs! AAPL & GOOG have to change these URLs periodically and 802.11 vendors add the new ones in a cat and mouse game. So the customer's phone and thus customer think they're connected but they end up hitting a CP. Why? Because the CPD browser will close immediately upon receiving unencumbered Internet access. While many just want the legal liability limiting I Agree button to be tapped, many others owners want customers to see their store promotion/ad flyer page for longer than a second, place a tracking cookie, and do other value adds.

The interests of Wi-Fi network operators and users are not aligned. Right now only equipment manufacturers directly profit off Wi-Fi service. Hotspot owners can only indirectly earn money through attracting more hotel guests, cafe customers, etc. Some now harvest customer MAC address and in-store walking behavior. Ideally hotspot owners could receive a revenue share for offloading traffic from LTE, which would give them an incentive to be more loyal to users and maintain quality of experience.

https://news.ycombinator.com/item?id=13369038

I use example.org for that. I wouldn't be surprised if it has to stay available on http for hysterical raisins, such as everyone using it in their tests and outage detectors.

> hysterical raisins

Thanks for making me smile!

http://detectportal.firefox.com

That's why I always use my DNS tunnel. You can bypass such system on almost all public wifi.

Almost all? You've had access to some pretty crappy captive portals.

In my experience most portals' firewalls block all traffic (at IP level) except ports 80 and 443, which are transparently redirected to their auth server. Tunnelling isn't an option because you just can't contact anything else.

And it's not like I'm describing something that's hard to do. You've been able to script this stuff in iptables forever.

DNS happens over port 53

Yes. I'm saying in my experience everything but 80/443 are blocked. Completely. 80/443 get redirected.

Edited parent for clarity.

Then how can they redirect you to anything in the first place? I type www.google.com in my browser and then what exactly happens next on the IP level? Think about it...

Sure, yup, oversimplifying to make the point. They are also transparently redirecting DNS to their own server.

My point is you can't "tunnel" out. Not for DNS, VPN or whatever. It's all blocked. The only services they let you access are their own to get you to authenticate. Even if you walked in with a complete hosts file (so didn't need to query any DNS server), you'd still not be allowed to connect, at firewall level until you authenticated.

> They are also transparently redirecting DNS to their own server.

Yes that's expected. So what does their DNS server do when I ask it for the IP address of google.com?

It could reply with anything, even a valid, correct response. The connection you make to that result is still going to be redirected to the portal.

> It could reply with anything, even a valid, correct response.

Which you actually need to do, to prevent locking the user out from the website they tried to access in the first place after authenticating, thanks to DNS pinning.

> The connection you make to that result is still going to be redirected to the portal.

Correct, but who cares? This is about DNS tunneling, there will be no connection anywhere, the DNS queries and their replies ARE the connection, so to say. How about reading up on what a DNS tunnel actually is? Considering your posts in this thread you have no clue how it works or at least have huge misconceptions about it.

Give you the IP address of their captive portal.

Two ways for doing DNS tunneling: 1. direct way, you pass to your server through port 53. 2. indirect way, you pass through a "official" domain that you own and make the DNS of where you are communicate with your server.

For 1. it's not open very often, indeed. But for 2. I see it open all the time, even in banks...

What are you tunnelling to? In a proper captive portal, it's blocked.

I'm not talking about just blocking DNS. Or just blocking know DNS services. A good captive portal just denies everything save the web/dns traffic redirected to an internal server running on the portal. That is until you log in and get explicit allow rights.

If your portal isn't doing this, if you can escape and actually connect to external IPs, it's not captive.

DNS isn't secure, all they have to do is capture and answer all queries on unauthenticated IPs. No route to the internet needed.

They can't do that. If they reply with a bogus IP then after you authenticate to the CP, you cannot access the website you tried to access in the first place (eg google) because now your browser has cached the wrong IP address that it got earlier.

So they need to lookup the actual IP address on your behalf and then in turn redirect traffic to that IP to their CP. boom, you just managed to communicate to the outside world.

They could just set a low TTL

No they couldn't, unless they expect everyone to use a browser that is vulnerable to DNS rebind attacks, which probably means some browser from the 90s.

Every browser is vulnerable to DNS rebind attacks, since the burden of "fixing" it has been pushed onto the applications that are getting traffic forwarded by the browser.

Also services like Cloudflare wouldn't work if low TTLs didn't work. CF rotate IPs often as part of their DDoS protection.

They still do. Not like when DNS rebind was all the rage, where Firefox decided to cache DNS replies forever, but they still bump the TTL to a minimum of several minutes, which is enough to confuse people in the CP scenario. I wouldn't be surprised if some OS resolvers did the same, possibly just for performance reasons even. And that's all fine and dandy since those couple minutes don't break the Cloudflare scenario.

I mean, if it weren't the case, why would CPs work in that way then anyways? It wouldn't be an issue to have a DNS server in the mix that resolves everything to you CP address with a TTL of one second, and then additionally to your port 80 TCP redirect just add another one for 53 UDP. It's not being done by any CP solution I have ever encountered.

Recent versions of Firefox should detect this and present a prompt to go to the portal login page.

http://1.2.3.4 or any other random IP generally works for me. It doesn't necessarily have to exist.

www.com is a short, easy to remember, parked domain I tend to use. It has some text ads, but is probably reasonably light on bandwidth.

neverssl.com, mentioned below, is one I seem to for some reason always struggle to remember it's name when I need it. I end up typing things like nossl.com or neverhttps.com and such...

example.com is great for testing http. And it’s owned by IANA and not some rando. No ads either and easy to remember.

For a long time I used my bank's homepage to get me redirected to the login page. Until the (reluctantly) forced HTTPS. Since then I'm using http://neverssl.com :)

http://http.rip/

http://info.cern.ch

captive.apple.com

Example.com is defined to not have ssl.

? https://www.example.com/ It's had HTTPS since at least 2014. [0]

[0] https://crt.sh/?id=5857507

That is a surprise to me, but you are right. I’m not quite sure what’s the use but there it is.

Defined by what or whom?

(I'm still sad that example.com responds to anything at all. It was originally defined as a completely unused, thus unresponsive, domain.)

Read example.com it answers all your questions :-)

It doesn't say that IANA defined it to not have HTTPS anywhere at all.

captive.apple.com

I love this site.

you also always have to disable your custom DNS settings, and sometimes that means disable your DNS over TLS or go without internet :(

hp.com is still not strict and is quick to type. No guarantee that they won't turn on HSTS tomorrow though.

neverssl.com ( not a suggestion, it does exist )

doesn't most OS's now have a captive portal which always check a url if it is accessible, if not they open a sane looking portal?

Reply on news.ycombinator.com