[HTTPS-E Rulesets] Various CDN issues - CloudFlare (blog broken), CacheFly (bug 6484?), EdgeCast mismatches (misnamed), EdgeCast (add), Voxel (broken?)

Christopher Liu cmliu00151 at gmail.com
Sat Aug 18 23:10:40 PDT 2012


To whom it may concern:

I grouped these issues together just because they all have to do with
CDNs ... another email will follow shortly.

The CloudFlare blog is now broken again. Although the cert is still
valid (from the CloudFlare CDN), the page shows an error message
(generated by the CloudFlare CDN) saying that the site is offline. The
site works fine when unencrypted, so I know it isn't really offline.
Obviously, it should not be readded to Posterous-clients.

--

The CacheFly ruleset is intended to match numbered subdomains of the
form 0.bucketname.cachefly.net, but it doesn't successfully do so. I
tested this both on 2.2 (by installing a copy of the ruleset as a user
ruleset) and 3.0development.6 (where the ruleset is built in). This
appears to relate to
https://trac.torproject.org/projects/tor/ticket/6484 if I understood
correctly.
For example, see the www.cachefly.com homepage, where the domains used
include 0.cachefly.cachefly.net, 1.cachefly.cachefly.net etc.

--

Edgesuite is part of Akamai, not EdgeCast. See
http://www.akamai.com/html/about/press/releases/2000/press_101800b.html
This means that EdgeCast-Networks-mismatches.xml should be renamed to
Akamai-mismatches.xml. (This is just a cosmetic/documentation issue;
no rules need to be modified.)

--

As for a working EdgeCast rule ... the 2-level domain edgecastcdn.net
is part of the CDN and appears to work fine. For example, it is used
on www.perpetualkid.com

--

The last change to the Voxel ruleset may have weakened its coverage,
but it may now be broken anyway.
It seems that \d\w* was intended to be \d[\w\-]*, given the Voxel
bucket names that I've seen.*
Although they are responsive with valid certs, most/all return 404 in https.
Voxel may have limited https support to a premium service tier at some
point, as mentioned by http://www.cdnplanet.com/cdns/voxel/
However, since Voxel has been acquired by Internap, I can't find
accurate documentation on the Voxel pricing plans.

Some specific examples to test:
3498-deltalab.voxcdn.com (appears to be a full copy of the site
www.deltalab.es ; requires Flash)
5601-blogs-nvidia-com.voxcdn.com/wp-content/themes/nvidia/images/bg-nav-a-span.png

(*If I have misunderstood, please give examples of domains the ruleset
was meant to cover.)

--

C. Liu

P.S. Not a defect, just a question: What's the policy on examining DNS
CNAME records (via nslookup, dig, etc.) to find CDN buckets? It seems
like this hasn't often been done; why?
I'm talking mainly about S3 and CloudFront, not the tricker CDNs like
Akamai and EdgeCast.
Specifically, this is what I did for PCPro.co.uk's CloudFront bucket a
few emails back.




More information about the HTTPS-Everywhere-Rules mailing list