Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NeverSSL

fdbhclmrkstnvwxz.neverssl.com

Post reply on HN
Print view View original

111–120 of 206 posts

Re: NeverSSL

#111

Post by conradev »

m0dest wrote: post #81

If you’re using a mainstream OS that automatically detects standard captive portals, the main reason why you’ll need this is for “tiered” captive portals like the ones offered on some airplanes. Those tiered captive portals have unique requirements that conflict with OS behavior: A) By default, they want to offer some limited Internet access, such as accessing a sponsored site (often a shopping site like Amazon) or s…

The closest thing I know of is Wi-Fi Passpoint: https://www.wi-fi.org/discover-wi-fi/passpoint

but I think it lacks the features necessary to do tiered auth

Re: NeverSSL

#113

Post by 2arrs2ells »

danShumway wrote: post #103
m0dest wrote: post #81

If you’re using a mainstream OS that automatically detects standard captive portals, the main reason why you’ll need this is for “tiered” captive portals like the ones offered on some airplanes. Those tiered captive portals have unique requirements that conflict with OS behavior: A) By default, they want to offer some limited Internet access, such as accessing a sponsored site (often a shopping site like Amazon) or s…

Adding another question on top of this, does anyone know how widespread DNS over HTTPS affects this model? I guess you could do filtering based on IP address, but that seems really fragile as well? I'm guessing that the way it works today if you're pointing to a non-standard DNS server like Cloudflare's, is that the portal still just intercepts and modifies those requests anyway.

I’ve found that non-standard DNS often prevents access to WiFi portals. Removing the Google/Cloudflare dns settings is step # 2 in my public WiFi debugging checklist (after trying to visit neverssl).

Re: NeverSSL

#114

Post by shakna »

amarshall wrote: post #99
ramshorns wrote: post #65

Earlier quoted context omitted.

This could also happen because of an extension like HTTPS Everywhere, which requests the https by default when both are available.

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.

It also sends the "Upgrade-Insecure-Request" header, which can cause that switch to take place.

Re: NeverSSL

#116

Post by monocularvision »

tprynn wrote: post #22
monocularvision wrote: post #15

Earlier quoted context omitted.

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 dete…

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.

That’s why I just use neverlssl.com now.

Re: NeverSSL

#117

Post by gruez »

ComputerGuru wrote: post #102
maltalex wrote: post #95

Earlier quoted context omitted.

A GB of outbound transfer on AWS costs about 0.09$. If the page is 55KB, that means that a single GB is about 18K page loads, but let's make that 15K page loads due to various overhead. To spend 2000$, you'd need to send about 22TB, which are about 330M page loads.

But that’s not accounting for gzip.

This. Firefox's dev tools says 3.38KB transferred (including redirect and favicon). Taking that into account, it's closer to 5 billion page loads.

Re: NeverSSL

#118

Post by organsnyder »

Thorrez wrote: post #35
etskinner wrote: post #6

http://example.com also does this, albeit without the promise of never switching

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 .

The Firefox instance I'm using at the moment goes to the non-TLS version when I type "example.com" in the address bar.

Re: NeverSSL

#119

Post by dmurray »

profmonocle wrote: post #76
crazysim wrote: post #39

Earlier quoted context omitted.

I think the only promise example.com has is that the domain will always exist.

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.)

"the domain will exist" does not mean "someone will run a web server there and respond to traffic", though.

Though I'm not exactly sure what it does mean. That it will have at least one DNS record?

Re: NeverSSL

#120

Post by MrStonedOne »

_bxg1 wrote: post #90
saghm wrote: post #53

Earlier quoted context omitted.

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 t…

Thanks for the explanation - I've definitely encountered that situation. Do you know why it works that way?

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.
Post reply on HN