[sublimino]

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

[AlyssaRowan]

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.

[sublimino]

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.

[geographomics]

> 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?

[claudius]

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

[geographomics]

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

[claudius]

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.

[geographomics]

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?

[AlyssaRowan]

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.

[geographomics]

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

[jsprogrammer]

What is the reason for the shared certificates?

[captn3m0]

Cloudflare is offering free SSL certificates to anyone. Using shared certificates keeps the costs down.

[jsprogrammer]

In what way does it keep costs down?

[kelnos]

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.

[captn3m0]

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.

[kelnos]

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.

[tallanvor]

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.

[sublimino]

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.