Originator/Maintainer of NeverSSL here. AMA. Funnily enough, I'm on a plane to Fresno right now, and I used it to get online.
FAQ:
1. Why does neverssl.com use Javascript to redirect to a random subdomain?
Over the last year users reported that some networks aggressively cache the fake DNS and pages they use for wifi capture. Neverssl.com now works around this generating a request to a random subdomain - this will bust any DNS cache, and any HTTP cache. It also means that if your browser or ISP caches the Neverssl.com page itself, that's fine.
2. Is NeverSSL.com tracking you or anything like that?
Normal S3 access logging is enabled, so I have a record of every IP address that accessed NeverSSL.com. I aggregate this information by AS number (ISP basically) to "rank" the networks that get the most usage ... this helps me figure out which networks are most broken. I occasionally forward this aggregated data to those network operators to encourage them to fix wifi capture. There's no other tracking, but you are trusting me on that. I am a founding director of Digital Rights Ireland, we sue governments and win for better user privacy.
3. Can I put ads on NeverSSL.com?
I thought about this, but I think it'd degrade the experience too much. I am thinking of maybe putting some rotating art, or inspiring poems, something to add a bit of soul to our day. Ideas welcome!
4. Shouldn't I use example.com?
I predict that example.com/org/net will all go HTTPS, as they are intended to service as canonical examples of internet standards.
5. What happens if NeverSSL.com gets pwned?
I don't understand this risk; it's not setting cookies, there's no passwords, or any personal information.
> I don't understand this risk; it's not setting cookies, there's no passwords, or any personal information.
I agree with you technically, but in practical terms imagine if you changed the web page to look like a Google-style search engine window.
You can expect all the less-sophisticated users to try typing site names and even URLs into that text widget.
And if you give them back what looks like a link to the place they wanted, they absolutely will click it, and most of them will happily trust that having typed "My Bank" and clicked a link labelled "My Bank: A secure bank" in the resulting "search results" the site they've reached, fake.mybank.neverssl.com must obviously be their bank, and they will cheerfully give you their bank credentials.
I'm not suggesting this as a criticism, it's purely an observation, that in practice NeverSSL getting pwned would be a real problem, the same exact way it's a problem when some Hollywood actress (who doesn't know the first thing about medicine) tells women not to vaccinate their kids. People are dumb, and we have to allow for that.
I always just use http://example.com since it's managed by ICANN and if it ends up pwned then we have bigger problems. I don't know who is behind this one, or whether it will stick around or be sold off later. Example.com is (basically) forever.
I used example.com in the past, though at some point I was looking whether there's any commitment from them never to default to HTTPS or use HSTS. Haven't found any.
So I found it better to use some domain dedicated exactly for this (and I hope even if the person running neverssl.com chooses to stop doing so someone will probably take over).
I'm being hyper-pedantic here. Wouldn't the relevant kind of pwning happen to you rather than to the site? I'm thinking something like a MITM at your local coffee shop's wifi or an evil employee at your work. If someone took over the machine serving example.com, HTTPS wouldn't have stopped it or helped alert anyone to it.
The point is to generate a 302 redirect, so I guess it doesn't matter what example.com is actually serving if you never see it. But the captive portal may forward you along to it after you authenticate.
This doesn't do anything to prevent a MITM at all, just that if neverssl.com starts serving crap you have a nonzero chance of loading it when trying to use it to generate a redirect. If there's a local MITM you're in trouble either way.
That makes sense. My one change to the workflow is that I tend to visit example.com again, one last time, after jumping through the captive-portal hoops to make sure it's all really working. Thus I do see the content.
+1 for example.com here. IMO "SSL" is not great to use in the domain name as non-tech folk have no idea what it is and might struggle to remember it. "NeverHTTPS" might be better, but even then how many people know their connection isn't working because of HTTPS? I'd wager not many.
I'm kind of amazed no one has implemented a better system for this yet. Public WiFi is very common, and relying on intercepting HTTP requests to show users a login screen seems very hacky to me.
What if a device pinged the gateway IP on a certain port whenever it connected, and received a small payload with details on connectivity authorisation URL, etc. etc.? For backwards compatibility if that ping fails it could just assume the network is open. It would take years for all the public routers out there to be updated, but you kind of need to start somewhere.
There are better systems, for example RFC 7710 defines how DHCP and RA (the methods devices use to get themselves an address from a network) can tell a device about a captive portal, which is the thing that hijacks your access to the Internet and tries to show some sort of "login screen". There's a current IETF working group, capport, doing 7710bis and other work in this area.
But the existence of a better solution doesn't stop people doing something crummy that kinda-works for them. That's what you're seeing today, it's what you see in most places, most of the time. That's people.
Perhaps the folks running these networks lack the incentive to care about technical correctness? OTOH, one would think a better system would lead to a higher conversion rate (i.e. more people are actually able to pay you).
Yeah, for "free wifi", the incentive is definitely to not connect you. You don't consume bandwidth, so the handful of people who do connect won't complain about shitty speeds.
For paid wifi, on the other hand, wouldn't they want to ensure you can connect? Most airlines charge for wifi. Yet I find myself typing "example.com" on almost every single flight.
There is incentive to connect you to the wifi, but no to the internet. Having you trapped behind a captive portal is perfect for this. You are connected to their wifi so they can more accurately track you through the store, but you are not using their internet bandwidth.
The homepage is fairly innocuous, it’s always http, and if it loads I also know the WiFi doesn’t have some crappy web filtering software running on it.
Looking at DNS and the resolved Its, it's hosted via CloudFront and (I'd imagine) an S3 bucket. On the other hand, the creator is a fairly prominent employee of AWS, so that's hardly surprising.
The only tracker on the page is from Twitter (for the follow button). I don't know what metrics they give you, but other than that it looks to be whatever can be grabbed from the server side logs.
I've been using this for several years now both to test internet connectivity and to force captive portals to load - I didn't know about example.com until today though!
The MITM to make you agree to a pointless EULA for using wifi is one of the most obnoxious things going. I know this trick (I've usually used http://fark.com) but non-technical people don't know it and as such public wifi is largely useless to them because of the MITM they use. Also, plenty of public wifi is flaky and as such by the time you've loaded the authentication page, you've lost your signal and need to re-auth!
Related: browser is confused and caches some of the captive portal content for the site you want to visit, so it remains broken even after the portal lets you through. Add a cache-buster to the end of the URL -- ?a=1 for example -- and most webservers will handle the modified URL without complaints.
I often find my self having to use Firefox to get online on public WiFi. Firefox have frequent requests to their own servers using only http to circumvent this problem.
FAQ:
1. Why does neverssl.com use Javascript to redirect to a random subdomain?
Over the last year users reported that some networks aggressively cache the fake DNS and pages they use for wifi capture. Neverssl.com now works around this generating a request to a random subdomain - this will bust any DNS cache, and any HTTP cache. It also means that if your browser or ISP caches the Neverssl.com page itself, that's fine.
2. Is NeverSSL.com tracking you or anything like that?
Normal S3 access logging is enabled, so I have a record of every IP address that accessed NeverSSL.com. I aggregate this information by AS number (ISP basically) to "rank" the networks that get the most usage ... this helps me figure out which networks are most broken. I occasionally forward this aggregated data to those network operators to encourage them to fix wifi capture. There's no other tracking, but you are trusting me on that. I am a founding director of Digital Rights Ireland, we sue governments and win for better user privacy.
3. Can I put ads on NeverSSL.com?
I thought about this, but I think it'd degrade the experience too much. I am thinking of maybe putting some rotating art, or inspiring poems, something to add a bit of soul to our day. Ideas welcome!
4. Shouldn't I use example.com?
I predict that example.com/org/net will all go HTTPS, as they are intended to service as canonical examples of internet standards.
5. What happens if NeverSSL.com gets pwned?
I don't understand this risk; it's not setting cookies, there's no passwords, or any personal information.