My favorite to use is http://perdu.com/ I don’t know where I found it, but it’s charming!
I think it's common in France. I've been using perdu.com for long for that purpose.
NeverSSL
91–100 of 206 posts
Re: NeverSSL
#92You can also use Microsoft's Network Connection Status Indicator (NCSI) URL: http://www.msftconnecttest.com/
Also has an IPv6 endpoint: http://ipv6.msftconnecttest.com/
Re: NeverSSL
#93You can also use Microsoft's Network Connection Status Indicator (NCSI) URL: http://www.msftconnecttest.com/ Also has an IPv6 endpoint: http://ipv6.msftconnecttest.com/
Not nearly as memorable.
Re: NeverSSL
#94Re: NeverSSL
#95http://neverssl.com/changes > I also want to keep neverssl.com ad free, but as it's now costing me about $2,000 a year to host it, […] Wait, how could hosting a static website cost $2k/year?!
Bandwidth, maybe? That page is 53.8 KB total. $2k does seem high though.
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.
Re: NeverSSL
#96http://neverssl.com/changes > I also want to keep neverssl.com ad free, but as it's now costing me about $2,000 a year to host it, […] Wait, how could hosting a static website cost $2k/year?!
from the same page: > it's just a simple website hosted on AWS lots of ways of spending a lot of money on hosting a website on AWS. Hard to judge precisely without traffic numbers.
That page says 6 million hits per day.
Re: NeverSSL
#97Earlier quoted context omitted.
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.
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.
Re: NeverSSL
#98Earlier 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?
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.
Re: NeverSSL
#99Earlier quoted context omitted.
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 hav…
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.