Ask HN: What to do when CloudFlare is on an Adult block list
11 comments
Shared SSL certificates from CloudFlare are also loaded with porn sites. For https://www.binarysludge.com
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...
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...
Wouldn't help in general. Firstly, lots of sites on Sky's default block list aren't porn.
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.
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.
Wasn't suggesting StartSSL as a solution for the OP, just as an aside on CF's SSLs. But https://letsencrypt.org/howitworks/technology/ looks great, thanks. Bring on Summer 2015.
Probably a good time to name-drop https://www.blocked.org.uk/ to verify blocked domains too.
Probably a good time to name-drop https://www.blocked.org.uk/ to verify blocked domains too.
> charges for revocations (even after Heartbleed) in clear contravention of CA/B Forum guidelines
The guidelines don't state that revocations must be free of charge, where are you getting that from?
The guidelines don't state that revocations must be free of charge, where are you getting that from?
Point 7.1.2.8 states that "the CA Will revoke the Certificate for any of the reasons specified in these Requirements". This is a warranty made by the CA towards all "Certificate Beneficiaries", which includes "All Relying Parties who reasonably rely on a Valid Certificate", i.e. the general public.
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
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
But if you look at the bylaws of the CA/B forum [1], they explicitly exclude discussion of "pricing policies, pricing formulas, prices or other terms of sale" as part of their mandate.
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...
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...
I’m not against revocation charges per se, I’m against charges being paid prior to revocation. So a CA including something like “if we have revoke this cert, you have to pay 20$, we will revoke under these circumstances: …” would be perfectly fine with me – terms in legal contracts requiring one party to pay a certain amount if certain situations arise are not uncommon, so I don’t think this would have legal issues.
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.
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.
Could you outline a scenario where you make a request that someone else's certificate be revoked, yet it's of such little importance that you refuse to pay the $25 fee that may possibly be charged?
SHALL here is an RFC2119 term which is unconditionally binding, like REQUIRED or MUST: "the definition is an absolute requirement of the specification". Zero wiggle room.
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.
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.
> After Heartbleed however, when presented with a huge list of compromised certificates
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.
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.
What is the reason for the shared certificates?
Cloudflare is offering free SSL certificates to anyone. Using shared certificates keeps the costs down.
In what way does it keep costs down?
I assume CloudFlare has a TLS signing cert that chains to a cert from a CA that is trusted by browsers, so generating new certs is likely free for CloudFlare, but IPv4 addresses are not free, and not particularly abundant these days.
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.
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.
Cloudflare has to issue a single SSL certificate that is shared across multiple sites. The cost of a certificate is not proportional to the number of alternative names in the certificate, and is a fixed cost.
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.
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.
You're mistaken; certs with multiple SANs don't make use of SNI. SNI is used (required) when you have multiple distinct certs. CloudFlare is not using SNI likely specifically because of the IE+XP issues (among others) that you point out.
Yeah, I got the two mixed up. SNI doesn't mean multiple hostnames on a cert. It means multiple certs on the same IP.
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.
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.
If the customer can't afford to pay $20/month to use SSL from Heroku (which does seem to be a rather outrageous amount), they're not going to be able to afford to upgrade to the CloudFlare plan that allows them to use a custom SSL certificate.
CloudFlare offer free, "flexible" Universal SSL https://www.cloudflare.com/ssl - although it is terminated at their servers and still communicates with the target server via HTTP. This is what I'm using for a simple blog.
> 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.
> 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.
You can get the client to disable this via the My Sky page here: https://secure.sky.com/mysky-homepage/indexb
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.
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.
Sky announced a couple of weeks ago that they intended to turn on their filtering by default. Maybe that's now happened.
Source: http://www.bbc.com/news/technology-30896813
Source: http://www.bbc.com/news/technology-30896813
Yes, it has been, from my metrics at least - with predictable results! (Seems to be a phased/tranched rollout.)
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.
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.
> Have you perhaps considered legal action against Sky?
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 :(
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 :(
This precisely fails to address the actual problem: his site is blocked for other users.
It seems that for the three people I have contacted, they have no recollection of being opted in to this adult blocking service
It asks you when you first connect the router. I suspect most people you have contacted are likely to have subconciously (or thoughtlessly) opted in.
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.
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.
A lot of people get technicians in to install the hardware, their default mode is to just next,next finish until the router is ready. Chances are it's the technicians themselves turning on the blocking. Not in a malicious or tinfoil hat way, just out of a desire to get the job done quickly
I can't let you know the URL, but http://medfirstalert.com/ is one of the other seemingly okay domains on this IP
That's fair.
The domain above resolves fine with and without the block: http://i.imgur.com/AIqtrxF.png
DNS cache was flushed between each hit.
The domain above resolves fine with and without the block: http://i.imgur.com/AIqtrxF.png
DNS cache was flushed between each hit.
If you have an engineer set up the router, they may just click though the screen as part of the set up, or bypass the traditional set up to save time.
Probably because the government told ISPs that opt-in should be the default.
I'd spin it differently - "Sky has put some of your site on the Adult block list."
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.
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.
Getting the IPs remoed from Sky's list might be a viable solution, but I think just opting out of the adult blacklist isn't. The client probably cares substantially about whether his site is visible to the (I assume) many people in the UK who haven't opted out.
Does anybody else think that $20 a month for a SSL certificate is way too much, Heroku or not? I can get a domain-validated SSL certificate for $5.95 per year and even providers of shared hosting are able to install it at no cost (WebFaction and NearlyFreeSpeech come to mind).
Heroku doesn't do a great job explaining what that $20/mo provides - it's not for a SSL certificate. It's for a SSL terminating load balancer that sits in front of your app instances.
That's still very expensive, Cloudflare offers it for free, with a free certificate.
That Cloudflare offers it for free doesn't change the economics for everyone else. They do a lot for free that anyone else would charge for. IP allocations are not free, extra load balancers are not free, labor to set up custom certs on load balancers is not free. If you put a CDN in front of your site and want SSL termination on it, then every node in every location needs to have that cert installed and potentially an extra IP address for it, each. Companies aren't charging extra for SSL solely because they think they can gouge you on it; it's really not free to deploy.
Happily CloudFlare has offices in the UK, so it is a good thing you brought this issue up with them. I'm sure they'll have some quick mechanisms to fix this already.
Collateral damage from David Cameron putting pressure on ISPs to block inappropriate content.
Actually this is likely Sky's opt-in adult content filtering. It really isn't mandatory.
Any content blocking is prone to false positives and people will learn that eventually.
Any content blocking is prone to false positives and people will learn that eventually.
Sky's filtering is now opt-out:
> 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...
> 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...
When the whole opt-in opt-out thing hit the news I remember all the press was insisting it was opt-in. Simply insisting, then basing their arguments off that.
Not mandatory though, that's most the important thing.
Buy a cheap SSL cert from RapidSSL ($11/year via namecheap). Get $5 DigitalOcean server, and reverse proxy whatever you're serving with nginx. Done for $5/month.
Bonus points: get the guy a private VPN on there too.
Bonus points: get the guy a private VPN on there too.
Why did it take an hour of investigating -- I mean, What message was the client getting from the filter? (And why are clients so terrible at reportin error messages?)
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
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
We had to find some more people on the same ISP to find it was SKY that was the problem
You haven't really stated why they're using CloudFlare - is it for the free TLS?
To be honest if they can't afford the $240/year to get TLS added to Heroku perhaps they've got bigger problems?
To be honest if they can't afford the $240/year to get TLS added to Heroku perhaps they've got bigger problems?
[deleted]
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.