I just use connectivitycheck.gstatic.com/generate_204. The URL is a bit long, but I have it bookmarked.
NeverSSL
61–70 of 212 posts
Re: NeverSSL
#62Re: NeverSSL
#63Easier to type and they never plan to add HSTS because of that reason.
Re: NeverSSL
#64I don't get it. What does it do stop redirecting users to the https version?
Basically, it's designed to be easy to remember, and over time I'll deploy whatever "Nope, really use HTTP" workarounds are available as TLS-by-default, and maybe even DANE, gain traction.
The difference between neverssl.com and others is just that "guarantee" and the slightly tongue-in-cheek text that tries to make it clear to users what's going on.
Actually right now I'm on a plane, between Newark and Seattle, and just typed it in to log in ... only to see it featured on HackerNews. Mind Blown. I'm coming back from 7 days spent with other implementors of TLS, and it's something I stay up to date on. That's it.
It's pretty weird that example.com does not use https:// , I expect it will in the near-future. Part of its job is to set a good ... example.
Re: NeverSSL
#65I don't get it. What does it do stop redirecting users to the https version?
Re: NeverSSL
#66Earlier quoted context omitted.
> why there isn't a better solution... There is a better solution: No captive portals.
What would you suggest for the case of someone wanting payment for the connection? Like it or not, a lot of places do that.
I think we should move towards considering Internet access as a general service that people make available for their guests/customers.
Re: NeverSSL
#67I don't get it. What does it do stop redirecting users to the https version?
It doesn't. It loads a page that's HTTP only, so that the wifi provider's login page can be displayed without an SSL error.
AHA! That's it. Now it makes sense.
Re: NeverSSL
#68It's sad, because these are the kinds of things that confuse the hell out of "common folk" and explaining requires explaining HTTPS, HSTS, how captive WiFi portals work, and then ultimately, why there isn't a better solution... which maybe doesn't have a great answer. I feel like this "workaround" site is designed to draw attention to the problem at hand more than it is meant to be useful for the task at hand?
This isn't generally a problem on smartphones and tablets because they can usually detect captive portals and prompt the user appropriately.
I don't travel often (Christmas and maybe once or twice a year outside of that), but it's when I encounter this. It's very frustrating because I'll be walking, pass a store I've previously connected to Wifi, and suddenly lose Internet, then hunt for a website to get the portal to pop up.
I'm annoyed that captive portals have been commonly using DNS hacking since 802.11b and I'm surprised a better solution hasn't been standardized. I have no idea where in the stack it should go (DHCP, wireless standards, or whatever) but DNS hacking drives me nuts.
Re: NeverSSL
#69example.com works as well. it doesnt redirect to https://example.com
http://captive.apple.com/ also. That's what Apple devices use when trying to present the login for a captive network.
Re: NeverSSL
#70Not sure about Apple, but isn't this automatically handled by Android these days? Every time it connects to a network it pings http://google.com/generate_204 and if the response code isn't 204 then it should prompt you to open the browser to the redirected URL.