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.
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.
Sorry, I understand all of that. This was not one of those situations. I could not get to any place on the network because they had a captive portal but iOS didn’t know to open it because they allowed captive.apple.com through. After navigating to neverssl.com I was properly redirected to the captive portal and able to agree to whatever guest WiFi terms were available.
In both Chrome and Firefox, when I type "example.com" into the URL bar, I go to https://example.com , probably because I've visited the https site before and they remember that. So I do not recommend example.com .
I don't think the IANA domains make use of HSTS or anything of the like.
HTTP/2.0 304 Not Modified
cache-control: max-age=604800
date: Sat, 02 Nov 2019 22:22:19 GMT
etag: "3147526947+gzip"
expires: Sat, 09 Nov 2019 22:22:19 GMT
last-modified: Thu, 17 Oct 2019 07:18:26 GMT
server: ECS (sjc/4E71)
vary: Accept-Encoding
If you type "example.com" into the URL, both Firefox and Chrome will try HTTPS first. If you want plain HTTP, you just need to ask for it: "http://example.com"
I don't think HTTPS is the default automatically. When I create a new Chrome profile, then type example.com into the url bar and hit enter, I go to http://example.com . Then when I type https://example.com twice (each time hitting enter) then type example.com and hit enter, I go to https://example.com . So I think it might be whichever is more common in your history.
Firefox behaves very similarly, except I don't have to visit https://example.com twice before it becomes the default, I just have to visit it once.
HTTPS Everywhere uses built-in rules, not heuristics, to determine when to rewrite an HTTP request to HTTPS. There does not appear to be a rule for example.com, so HTTPS Everywhere does not cause a rewrite.
For Firefox, this may occur when the address bar autocompletes from history, pulling the https:// entry. As far as I can tell, it doesn’t have anything to do with prioritizing HTTPS, just whichever is more frequent in your history (if you visit the HTTP enough times it will switch to picking that for autocomplete). If you don’t use the autocomplete entry (for example, by tab-completing it but deleting the trailing slash), then it will use HTTP unless you actually typed https://.
* neverssl might be bought out, or re-registered, at some time in the future.
* example.com is a IANA reserved domain [0], which whilst it doesn't guarantee they'll never deploy SSL, does mean nobody else can register it, ever (RFC 6761) [1].
Has an interesting WHOIS record too. The "registrar" is "RESERVED-Internet Assigned Numbers Authority", and no admin/technical/billing contacts like in standard whois entries.
http://example.com/ does deploy HTTPS https://example.com/ - but a redirect from http is unlikely, at least until the .com TLD is HSTS preloaded (and this might not be for another 10 years or so).
I'm not sure that's even true. RFC 6761 says "IANA currently maintains a web server providing a web page explaining the purpose of example domains."
Saying "currently" implies it's not guaranteed to always be true. (Although it's more likely to stick around than a random domain registered by a hobbyist.)
This is very pedantic, but technically nothing requires an HTTP service to be hosted at example.com. It's only guaranteed to be reserved and never assigned to a real organization at the DNS level.
It's just your standard parked domain. I typed it in when I was frustrated one time trying to log into a public wifi. It worked and I didn't even understand why back then.
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.
Consumer operating systems started detecting captive portals long ago, and at a time when HTTPS was much less common than it is today for casual usage. Post-Snowden, there has really been a multi-industry push to use HTTPS everywhere even for "boring" use cases where a naive person wouldn't assume snooping to have much consequence. But captive portal detection appeared from Microsoft, Apple, Google, etc. years before that push.
HTTPS absolutely should reject a captive portal trying to hijack it, that is the point of it.
But "work around HTTPS" remains a weird way to describe this. The captive portal is the culprit in need of a workaround, not https which is doing what it's supposed to be.
I miss the old purple page at purple.com which unintentionally served the same purpose. Comcast techs used to use it as a test for whether you were in their captive portal.
Probably avoid caching. Just taking a guess, but you do not want your DNS cached when the poorly-programmed router login page is trying to spoof DNS, and redirect you to their login portal.
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.
Of course some portals do use DNS and so you end up with your favorite site's home page getting a bunch of irrelevant arguments appended to it, resulting in an error page.
I’ve used http://www.fake.com for years just because it worked. If that London-based artificial plant company ever goes out of business, I don’t know what I’ll do! ;)
Serves a completely different purpose but I also frequently use badssl.com for testing TLS configurations (for instance you can load it on a kiosk, gym screen, etc - if it loads successfully then your connection is not being verified and could be MITM-ed)
So, sites like this are useful. (It's certainly better than memorizing the URL that various hotels use for their wifi portals, which I have done before, sadly.) But is there anybody working on solving this problem transparently to the end user? It seems user-hostile to require people to remember a non-HTTPS URL, especially as more and more sites move.
And if you think there are things that need doing beyond RFC7710 (you would be correct) the place to go help/ bring your ideas is the IETF's capport (Captive Portal Interaction) Working Group: https://datatracker.ietf.org/wg/capport/about/
Some wifi networks will display a login/payment page to you by mitm'ing your connection & replacing the page you tried to load. But of course this only works for HTTP pages.
Some WIFI networks require a login like airports or hotels. When you use https sites it wont redirect to the proper “wifi login” page as it should. This site being http should redirect you to that “wifi login” page
"This website is for when you try to open Facebook, Google, Amazon, etc on a wifi network, and nothing happens. Type "http://neverssl.com" into your browser's url bar, and you'll be able to log on."
I don't get it. How does browsing to http://neverssl.com help you to log in to other websites?
If the WiFi has a login portal, you might not get redirected to it when accessing an https site. If you go to this site, you’re more likely to get properly redirected.
It lets you access the portal to connect to wifi by allowing the router to MITM the connection due to the lack of SSL and bypassing caching with the random subdomain. After successfully connecting through whatever custom router software you'll be able to log in to those other websites.
On some public wifi networks, you need to load a captive portal page and hit a button (usually to accept terms and conditions) before network to route you to any actual sites. The network often enforces this by redirecting you to that page whenever you try to visit something else. However, this doesn't occur properly when accessing a page with HTTPS. The easiest way to to directly to to the captive portal is to try to go to a non-HTTPS site, but fewer and fewer sites provide this (for obvious securityv reasons). The purpose of this site is to provide an easy-to-remember domain that the owner guarantees will never use HTTPS so that users of such networks can type it in as a way to load the captive portal. I've used it a number of times when using wifi on Amtrak trains.
Captive portals require intercepting and redirecting your HTTP request. You can't do that with HTTPS because it's encrypted. Most sites now automatically redirect to HTTPS and are cached that way by browsers so it's hard to find a HTTP-only site that will get redirected on these networks.
Websites can tell browsers to never connect to them via unsecured channels (hsts/hsts preload), in a secured channel the browser validates the server's encryption certificate is authorized to encrypt traffic for that domain, so the wifi network can not intercept it to serve up the captive porter.
You don't use a lot of hotel, airplane, airport, guest or otherwise captive portals do you? Most will gracefully redirect but a lot are painful. Add in things like HSTS (can't just go to Google), HTTPS Everywhere, etc and it's downright annoying to get to the portal.
NeverSSL is a huge frustration reducer, especially as I've been able to just tell less technical able co-workers to just go there.
One trick that often works at hotels is to enter the hotel's domain name, which typically has an entry in the wifi DNS. I don't know how that works related to SSL, I just know it often solves the problem.
Never had any issues typing http://google.com manually and having that get redirected to the capture portals. Obviously you have to specify the protocol otherwise modern browsers will try https first.
Well now that text isn't very helpful, might be cached by any middlebox or endpoint. I expected at least a time like "Yes as of 2019-11-03T19:19:19Z" (I have a subdomain, http://time.lucb1e.com, that does I use for this)
They might not run a web service indefinitely, nor did anyone ever say they'll not redirect to https. It happens to work just like a random other 90s website might work.
Even with technical prowess - I'm a software developer and spent much of today designing a cloud load balancer architecture for a startup's global infrastructure - I had never realized that this issue had to do with SSL.
I usually just futz around with things like the local gateway IP or the business's domain name (e.g. hotel domain name) until it works.
I always used my own IP until I got to a portal that didn't work with that. Now I use a subdomain of my site. Then one very smart captive portal "moved permanently"'d that and my browser cached it, as it should, and on the next WiFi it tried to load the old one's captive portal x_x. Not sure what the solution is for that, it would happen with neverssl or any of the alternative domains mentioned here as well. I guess you'd have to manually type a random subdomain of neverssl or so.
205 comments
[ 2.9 ms ] story [ 206 ms ] threadThat’s why I just use neverlssl.com now.
edit: woah, two other comments at the same time pointing it out.
There should be no forced https redirection if you fill in http:// prefix by hand though. At least for now, until example.com adds HSTS headers.
Firefox behaves very similarly, except I don't have to visit https://example.com twice before it becomes the default, I just have to visit it once.
* neverssl might be bought out, or re-registered, at some time in the future.
* example.com is a IANA reserved domain [0], which whilst it doesn't guarantee they'll never deploy SSL, does mean nobody else can register it, ever (RFC 6761) [1].
[0] https://www.iana.org/domains/reserved
[1] https://tools.ietf.org/html/rfc6761
Saying "currently" implies it's not guaranteed to always be true. (Although it's more likely to stick around than a random domain registered by a hobbyist.)
Though I'm not exactly sure what it does mean. That it will have at least one DNS record?
It's just your standard parked domain. I typed it in when I was frustrated one time trying to log into a public wifi. It worked and I didn't even understand why back then.
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.
You can argue the merits of this being a good thing or not. But it’s fair to call it a work around.
HTTPS absolutely should reject a captive portal trying to hijack it, that is the point of it.
But "work around HTTPS" remains a weird way to describe this. The captive portal is the culprit in need of a workaround, not https which is doing what it's supposed to be.
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.
I don’t know where I found it, but it’s charming!
Yes. RFC 7710 defines a DHCP option to supply a URI for a captive portal page.
https://tools.ietf.org/html/rfc7710
[Edited to add] The problem is that websites that require ssl prevent you from getting into the login portals.
I have http://detectportal.firefox.com bookmarked on my phone for this exact reason.
I don't get it. How does browsing to http://neverssl.com help you to log in to other websites?
NeverSSL is a huge frustration reducer, especially as I've been able to just tell less technical able co-workers to just go there.
detectportal.firefox.com
For me that means type "1", the browser fills the rest, hit enter: boom, captive portal.
YMMV, of course.
https://www.whatsmydns.net/#A/example.com
I usually just futz around with things like the local gateway IP or the business's domain name (e.g. hotel domain name) until it works.
0: https://chromium.googlesource.com/chromium/src.git/+/36b8980...