Ask HN: What to do when CloudFlare is on an Adult block list
We got a call this morning from a client that couldn't access his website from his home broadband (Sky UK). After an hour of investigation it turned out that one of the IPs that CloudFlare returns for the DNS query for the site is on an "Adult Content" blocklist.
Moving off CloudFlare is difficult now as Google has identified the clients site as SSL and the client doesn't have the budget for the $20 a month it costs to add SSL to Heroku.
I have contacted CloudFlare about this, but thought I'd mention to HN that some of the CloudFlare IPs are blocked in the UK on certain ISPs.
53 comments
[ 4.5 ms ] story [ 126 ms ] threadThe same thing can be said for shared-hosting.
Even vps recycle ips(ec2) ?
Any content blocking is prone to false positives and people will learn that eventually.
> What we’re doing now is simply making sure that the automatic position of Sky Broadband Shield is the safest one for all – that’s ‘on’, unless customers choose otherwise.
src: https://corporate.sky.com/media-centre/our-blog/2015/sky-bro...
I submitted the page you get from BT if you try to visit KAT. It might be useful if there's a collection of similar pages somewhere?
https://news.ycombinator.com/item?id=8989964
This is opt-in so they clicked a button somewhere when Sky asked them if they wanted adult content blocking.
If anyone opts in to blocking; it's their funeral. It doesn't work. Sky's blocking even kills ThinkPad wiki.
If you let me know the URL, I can test from here as I'm on the end of a Sky connection without the opt in blocking so that would confirm if it is that or not.
The domain above resolves fine with and without the block: http://i.imgur.com/AIqtrxF.png
DNS cache was flushed between each hit.
Source: http://www.bbc.com/news/technology-30896813
Don't get CloudFlare to budge you to another IP, you'll never know what may or may not be listed - most of the content on the default filter is not porn. This is Sky's problem, not CloudFlare's.
It's deplorable, but entirely predictable (and they were repeatedly and loudly warned!) that innocent bystander sites have been blocked by the censorship on Sky's broadband network that people haven't even asked for.
Have you perhaps considered legal action against Sky?
You may also want to let them know, but they can't admin the filter themselves (last I heard), so can't whitelist you, and the equipment they have cannot proxy the site on their list without also affecting yours. (That you share an IPv4 address is not itself an issue with CloudFlare.)
Don't mind me, I'm just getting snacks. This is going to get worse.
This is the real, correct solution but seems unlikely. The OP said his client is unable to shell out the extra $20/month for SSL on Heroku so it seems unlikely they'll want to pay for lawyers required for legal action :(
SANs: sni29282.cloudflaressl.com, .askporno.com, .binarysludge.com, .dzej.eu, .grem.eu, .hmtransportation.com, .joowaal.com, .kuwaitinfo.info, .le-foie-gras.eu, .mnmjewellery.com, .mobxnxx.com, .philippines2050.com, .pornfax.com, .pornhideaway.com, .pornmovies101.com, .shokweb.com, .tennistemptation.lt, .tennistt.lt, .the-porn-videos.com, .timenewroman.com, .tutoringunlimited.com, askporno.com, binarysludge.com, dzej.eu, grem.eu, hmtransportation.com, joowaal.com, kuwaitinfo.info, le-foie-gras.eu, mnmjewellery.com, mobxnxx.com, philippines2050.com, pornfax.com, pornhideaway.com, pornmovies101.com, shokweb.com, tennistemptation.lt, tennistt.lt, the-porn-videos.com, timenewroman.com, tutoringunlimited.com
https://www.sslshopper.com/ssl-checker.html#hostname=https:/...
Time to finally get that StartSSL cert I've been talking about...
Secondly, StartSSL is a terrible certificate authority who charges for revocations (even after Heartbleed) in clear contravention of CA/B Forum guidelines. Perhaps wait for Let's Encrypt later in the year instead.
Thirdly, this also affects shared hosting. We are now out of IPv4 addresses in RIPE, and we need encryption everywhere - IPv6 is one solution but SNI and shared hosting is an essential transitional tool. That's why CloudFlare have deployed it the way they have. Censorship simply can't be allowed to stand in the way.
Sky need to fix their shit here, which is to say, turn it back off by default.
Probably a good time to name-drop https://www.blocked.org.uk/ to verify blocked domains too.
The guidelines don't state that revocations must be free of charge, where are you getting that from?
Unfortunately, it is not made absolutely clear what "reasons specified in these Requirements" means. There are a couple of occurrences of "the CA SHALL revoke if X", but these are obviously not binding.
However, nowhere does it say that failure to pay on the side of the certificate recipient would be a reason for the CA not to do their job. I would also find it very weird if the quality of warranties made by a CA towards me depended on someone else paying the CA some money – in other words, I’m fine with the CA charging its customers to revoke certs, I’m not fine with the CA not revoking if its customers fail to pay.
EDIT: Link to PDF: https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf
So we can't assume a position for or against revocation charges - it's just not within the scope of the guidelines. Which are non-binding and advisory anyway.
[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Byl...
My problem is really that a CA says “we know this cert is bad but won’t revoke it, sorry about that”, just because the owner of the cert (someone absolutely irrelevant to me) doesn’t pay up.
The CA's policies on whether they charge for things in general (such as reissuing) falls out of scope of CA/B Forum - but some things are absolutely required if browsers are to trust a CA, like, say, § 13.1.5: "The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:" … "3. The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (also see Section 10.2.4 ['… If the CA or any of its designated RAs become aware that a Subscriber’s Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.'])…".
After Heartbleed however, when presented with a huge list of compromised certificates, StartSSL flatly refused the emergency action the other CAs took. "No, iI's [sic] upon the subscriber to take appropriate action, the certificate authority can't control or enforce which software to use". (What's actually required from the subscriber is "[a]n obligation and warranty […] to take all reasonable measures to maintain sole control of, keep confidential, and properly protect at all times the Private Key…" [emphasis mine]. Demanding subscribers' software or hardware to be totally bug-free would be great - but is clearly unreasonable today, especially in the wake of a major internet security event.) They confirmed they wanted to make money from it. "We don't get rich from this, but we can't lose either. It's part of the deal in favor of certificates for free." (Let's Encrypt will prove them wrong here.) So, it was clarified, they'll only revoke certificates if they're paid to? "The alternative would be to charge for every certificate, what do you prefer?" Any other way, at all? "No, there isn't." People asked if they were really serious. "Dead serious."
So if a CA refused to revoke their signatures on tens of thousands of keys they've been informed are compromised as part of a major internet security event, should we all continue to trust their word that any given key is truly authentic?
Fortunately, other CAs exist. But unfortunately, thanks to PKIX's design, any bad apple spoils the whole bunch unless there's some kind of external pinning to CA/endpoint public keys too (like HPKP and/or DANE). Revocation is enough of a problem child as-is, as agl already identified, without even CAs refusing to use it. Maybe going forward, things like ACME may let us more towards shorter-term endpoint keys instead? Who knows.
Possibly compromised. That's why it was the subscriber's choice, to decide in the balance of probabilities whether to revoke or not.
It's not like the Debian weak keys flaw where there was absolute proof of the private key being compromised - a database of all the possible keys (at standard lengths) were generated. In that case, StartSSL revoked the certificates automatically and free of charge.
As a downside to this, they have to use SNI, which is not supported in any IE+XP combination, along with a few older mobile browsers as well.
However, due to high costs behind getting IP addresses, CloudFlare does use SNI for its free tier. Its paid customers on the other hand get their own IP per hostname.
Customer-provided certs (using SNI) probably doesn't pass CloudFlare's compat tests as there are unfortunately enough clients out there that don't support SNI. The only alternative then, if SNI and multiple IPs are out, is a single cert with lots of subjectAltName entries.
> Flexible SSL: There is an encrypted connection between your site visitors and CloudFlare, but not from CloudFlare to your server.
> You do not need an SSL certificate on your server.
> Visitors will see the SSL lock icon in their browser.
It can be upgraded to full "strict" SSL all the way to the host with paid plans.
This security model obviously comes with some compromises, especially on login forms, as the user has been taught to expect the browser's padlock sign to signal an encrypted connection to the host.
To be honest if they can't afford the $240/year to get TLS added to Heroku perhaps they've got bigger problems?
This way you make it clear that it is Sky's fault and to make it work you just have to opt-out of the adult blacklist.
Bonus points: get the guy a private VPN on there too.