colmmacc / neverssl.com Goto Github PK

neverssl.com is serving https traffic on port 443. The certificate on https://neverssl.com is not valid for that domain (it looks to be a wildcard for *.cloudfront.net), but otherwise the content is the same as http://neverssl.com

Thanks for the awesome website. I often use this site to check if my internet is down or not, as my ISP will attempt to redirect non ssl pages.

A problem is that when I visit the site, Firefox gives me the cached version of the site, even if the internet is down.

Could you set a Cache-Control: no-cache header on the server response?

Icomera provide Wifi services to a lot of UK public transport services - including the train I get to/from work. For an unknown reason, they have started blocking access to neverssl.com. It is both puzzling and annoying - because it is train Wifi is a really good use case for neverssl.com.

I hope you don't mind me using this Github issue to track the progress with getting this sorted out.

This is the page that you see when connecting to neverssl.com:

When I visit http://neverssl.com it takes me to a page that says:
Type "http://neverssl.com/" into your browser's url bar, and you'll be able to log on.

So I would be going around in circles, no? I'm sure I'm missing something obvious, but I'm guessing usage would be something like; http://neverssl.com?url=<site_I_want_to_visit.tld>.

The function passed to sort is supposed to return the same value when given a specific pair of elements a and b as its two arguments (ref: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#Description)

prefix = prefix.split('').sort(function(){return 0.5-Math.random()}).join('')

does not meet this requirement. https://medium.com/@nitinpatel_20236/how-to-shuffle-correctly-shuffle-an-array-in-javascript-15ea3f84bfb has some commentary on why this is bad.

does not meet this requirement. https://medium.com/@nitinpatel_20236/how-to-shuffle-correctly-shuffle-an-array-in-javascript-15ea3f84bfb has some commentary on why this is bad.

There are various ways to do it correctly, either Fisher–Yates or the "assign a random number to each element" method. The former is more efficient (and doesn't have a problem if the function returns the same value twice), but the latter is shorter to implement in javascript (and the number of input elements so low that it practically doesn't matter):

prefix = prefix.split('').map(x=>[Math.random(),x]).sort().map(x=>x[1]).join('');

or non ES6 syntax:

prefix = prefix.split('').map(function(x){return[Math.random(),x]}).sort().map(function(x){return x[1]}).join('')

Is there a place where one can chip into the expenses of running neverssl.com?

We're in the process of launching https://github.com/dadrian/https-upgrade in Chrome. Right now, the feature is enabled for 50% of Chrome Beta, although you can also use it in stable (M113) by enabling #https-first-mode-v2 AND #https-upgrades on chrome://flags. We intend to enable this by default eventually, but we're not there yet.

HTTPS Upgrades optimistically upgrade any HTTP navigation to HTTPS. If HTTPS is unavailable, Chrome falls back to HTTP without an interstitial. The feature is not intended to protect against active adversaries.

Users can opt out of the upgrade feature on specific sites by adding the site to the "Insecure Content" "permission" accessible via chrome://settings/content or via the Page Info (Lock) Icon, and then navigating to an HTTP page on that site.

Putting this all together, what does this mean for NeverSSL?

1. Any Omnibox navigation to neverssl.com, regardless of scheme, gets upgraded to HTTPS.
2. Rather than serve a RST, NeverSSL sends a redirect to http://$RANDOM_SUBDOMAIN.neverssl.com
3. The HTTPS Upgrades feature intercepts the redirect to HTTP, and upgrades it to HTTPS.
4. NeverSSL happily serves https://$RANDOM_SUBDOMAIN.neverssl.com and the user is stuck on HTTPS
5. (optional, terrible workaround) The user clicks Page Info (Lock Icon) -> Site Settings -> Insecure Content -> Allowed
6. The user manually changes the scheme back to HTTP and forces a navigation (hits enter)
7. NeverSSL is now accessible over HTTP

Certainly, the UX for disabling upgrades is not good, although it's not entirely clear if there's any good options. What I don't understand is why NeverSSL supports HTTPS at all? I understand you did it to work around the schemeless Omnibox upgrades to HTTPS that landed a couple years ago, but wouldn't it work equally well to have port 443 return a RST, so that Chrome and other browsers immediately fall back to HTTP?

Alternatively, is there some way to serve a RST on the $RANDOM_SUBDOMAIN.neverssl.com on port 443, so that the redirect continues to stay on HTTP?

I love your site, and I use it at airports and hotels all the time. But sometimes it doesn't work because of browser caching. You say on the "changes" page that your intention is that "caching is aggressively disabled for that page". I don't see any of the headers that would normally help with cache-busting, though. I think they need to be restored for cache-busting to work.

As an example, here are the headers that I received in a recent test:

$ curl -sD - neverssl.com -o /dev/null
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 2536
Connection: keep-alive
Date: Mon, 15 Oct 2018 00:40:41 GMT
Last-Modified: Thu, 14 Jun 2018 00:16:40 GMT
ETag: "e8bb9152091d61caa9d69fed8c4aebc6"
Accept-Ranges: bytes
Server: AmazonS3
Vary: Accept-Encoding
Age: 7544
X-Cache: Hit from cloudfront
Via: 1.1 6eadd6c6c5a53c34c6fce458c34cd790.cloudfront.net (CloudFront)
X-Amz-Cf-Id: n0t3hLyn1Qh8vaPhsO7uAsMmUWLpjo5y_aUnK2oX26gDfDpftqb9Gw==

$

Can I please recommend that you add these HTTP headers to your page?

Cache-Control: no-store, must-revalidate
Pragma: no-cache
Expires: 0

Thanks again for your SSS.