Live data from Hacker News

NeverSSL

fdbhclmrkstnvwxz.neverssl.com

21–30 of 206 posts

Re: NeverSSL

#21
post #2

I use captive.apple.com if a public network fails to load the login/getting-started page.

I used the same until I recently hit a network that allowed that site but was captive for everything else. No idea what would inspire that configuration.

Whyyyyy... ugh that’s so dumb. That is just someone shooting themselves in the foot for no reason, or maybe some ex employee did something silly on the way out.

Re: NeverSSL

#22
post #2

I use captive.apple.com if a public network fails to load the login/getting-started page.

I used the same until I recently hit a network that allowed that site but was captive for everything else. No idea what would inspire that configuration.

iOS won't consider itself connected to a WiFi network until it can hit that domain and get the response it expects, but some networks want you to be connected even though they don't actually give you full internet access. For example, plane wifi networks where you can stream video to your device but would have to pay for actual internet. So those networks will allow the connection for that site and other captive detectors but intercept actual connection attempts.

Re: NeverSSL

#23
Why not just alksjdhflkjahdskjfhalskjdhfas.com or something that definitely doesn't exist? Since there's no HSTS on domains that don't exist, it should allow the wifi network to redirect to http://myloginportal/whatever and do its thing so you can access the network.

Re: NeverSSL

#25
post #7

I use captive.apple.com regularly but just realized that https was the issue being worked around on WiFi. Learning something new.

What do you mean by "the issue being worked around"? The issue is that https cannot be intercepted by such an access point, and is increasingly popular for all types of web use. "Being worked around" makes it sound like something different, perhaps even sinister.

He means that TLS on all domains breaks some use-cases and thus, in those cases, there needs to be some way of working around the situation presented.

You can argue the merits of this being a good thing or not. But it’s fair to call it a work around.

Re: NeverSSL

#26
post #23

Why not just alksjdhflkjahdskjfhalskjdhfas.com or something that definitely doesn't exist? Since there's no HSTS on domains that don't exist, it should allow the wifi network to redirect to http://myloginportal/whatever and do its thing so you can access the network.

you never know how poorly a restricted WiFi access point is implemented

Re: NeverSSL

#27
post #23

Why not just alksjdhflkjahdskjfhalskjdhfas.com or something that definitely doesn't exist? Since there's no HSTS on domains that don't exist, it should allow the wifi network to redirect to http://myloginportal/whatever and do its thing so you can access the network.

Some captive portals do TCP redirection, but no DNS redirection.

And for good reason. Once user has finished jumping through whatever hoops captive portal want them to jump, a new connection to the same server is likely to be attempted, and having a fake DNS response cached somewhere in libresolv or browser in the client is not the least bit conductive to that.

Re: NeverSSL

#29
post #27
post #23

Why not just alksjdhflkjahdskjfhalskjdhfas.com or something that definitely doesn't exist? Since there's no HSTS on domains that don't exist, it should allow the wifi network to redirect to http://myloginportal/whatever and do its thing so you can access the network.

Some captive portals do TCP redirection, but no DNS redirection. And for good reason. Once user has finished jumping through whatever hoops captive portal want them to jump, a new connection to the same server is likely to be attempted, and having a fake DNS response cached somewhere in libresolv or browser in the client is not the least bit conductive to that.

Ah, makes sense. I don't think I've encountered one like that, but I can imagine they exist.
Post reply on HN