[HTTPS-E Rulesets] Problems/fixes - AWS, Cam.ac.uk, Microsoft, Minus.com, Mozilla, OpenDNS, Statcounter, Tor2Web, Tumblr, WordPress

[Christopher Liu]

To whom it may concern:

This message concerns problems that should be fixed by adding
exclusions or disabling rulesets. Requests for enhancement will follow
in a subsequent message; sorry that this one is already rather long.
As a reminder, I am using Firefox and have not tested anything in Chrome.

Amazon Web Services:
Regarding www.spiegel.tv
(https://trac.torproject.org/projects/tor/ticket/4199), excluding the
domain spiegeltv-ivms2-restapi.s3.amazonaws.com gets the site to show
up correctly. I was unsuccessful finding a more targeted
exclusion/rule change.

Cam.ac.uk:
The certificate appears to be self-signed on the domain www.cl.cam.ac.uk .

Microsoft:
The https equivalents of some OEM-related pages such as
http://www.microsoft.com/oem/en/licensing/sblicensing/pages/licensing_for_hobbyists.aspx
http://www.microsoft.com/OEM/en/licensing/sblicensing/pages/localized_licenses.aspx
http://www.microsoft.com/OEM/en/licensing/antipiracy/pages/COA_hologram.aspx
and http://www.microsoft.com/OEM/en/installation/Pages/index.aspx give
404 errors.
Suggested exclusion pattern is
^http://(www\.)?microsoft\.com/(oem|OEM)/[A-Za-z]{2}(-[A-Za-z]{2})?/
(I have tested that these pages are available with the "oem" folder
either upper- or lowercase. I assume "en" is a language code, though I
don't know whether language+country codes like "en-US" are used, and
I'm not sure whether the language folder ought to be in the exclusion
at all.)

Minus.com:
blog.minus.com needs to be excluded because of ssl_error_rx_record_too_long.
The ruleset appears to break file downloads, at least for users who
are not logged in. The file link redirects back to the download page
rather than serving the file. The file links point to the domain
i.minus.com; excluding that may not help due to relative URIs on the
download page. Disabling the ruleset seems to fix this problem.

Mozilla:
blog.mozilla.com is now redirecting to blog.mozilla.org. HTTPS support
will be discontinued on blog.mozilla.com per
https://bugzilla.mozilla.org/show_bug.cgi?id=745883#c2
However, blog.mozilla._org_ does itself support https and will
continue to do so.

OpenDNS:
The domain info.opendns.com needs to be excluded because of no
response to https connections. It is used for some blog images; the
"OpenDNS User Groups" logo in
https://blog.opendns.com/2012/01/25/you-talk-tech-well-buy-the-pizza/
is an example. I am not using the OpenDNS DNS servers.

Statcounter:
Regarding gs.statcounter.com
(https://trac.torproject.org/projects/tor/ticket/5576), the fix in
2.0.2 doesn't entirely work for me. The chart area either gets stuck
at "Loading..." or displays "Sorry, JavaScript is required to view
Global Stats charts." Live HTTP Headers shows a 404 error for
https://gs.statcounter.com/MSLine.swf .
It works fine if I exclude gs.statcounter.com and www-beta.statcounter.com .

Tor2Web:
wiki.tor2web.org has cert problems and also different content in https
(specifically a 403 error).

Tumblr:
Embedded video players such as those used on
http://adobegripes.tumblr.com/ are broken (black image & no response
to clicking play). Excluding crossdomain.xml files doesn't solve this,
probably because the crossdomain.xml policies don't allow
s3.amazonaws.com.

WordPress:
Several Cheezburger Network sites encounter a cert mismatch when
loading font files from s.chzbgr.com. (This includes
icanhascheezburger.com, failblog.org, memebase.com and their
subdomains, except possibly failblog.org itself.)
The problem is in one specific stylesheet that misuses
protocol-relative URLs:
http://s0.wp.com/wp-content/themes/vip/cheezcommon2/style.css?m=1334014347g&ver=2012.04.04.1
(gets rewritten to s-ssl.wordpress...)
The query parameters change sometimes, but the rest of the URL does
not; in particular, the domain is always s0. Suggested exclusion
pattern is ^http://s0\.wp\.com/wp-content/themes/vip/cheezcommon2/style\.css
(I admit that this problem has existed for a long time and I haven't
attempted any tech evangelism. The issue may become obsolete after a
planned redesign of the sites, per
http://blog.cheezburger.com/announcements/welcome-to-the-new-cheezburger/
)

P.S. A couple things I'm not sure are reportable bugs:
Amazon Web Services: I understand that there exist 5+ level domains
foo.bar.s3.amazonaws.com that would not match the wildcard, so they
have to be rewritten to https://s3.amazonaws.com/foo.bar/.
However, the rule currently does this also for 4-level domains
foo.s3.amazonaws.com. This might break Flash content that has
crossdomain.xml files on such domains.
I propose handling 4-level domains the old way
(http://foo.s3.amazonaws.com/ -> https://foo.s3.amazonaws.com/) and 5+
level domains the current way (http://foo.bar.s3.amazonaws.com/ ->
https://s3.amazonaws.com/foo.bar/).
I don't have any specific examples of problems that are resolved by this change.

Regarding https://trac.torproject.org/projects/tor/ticket/4593 ,
Goodreads appears not to use CloudFront anymore (with rare exceptions
being images in old blog posts). However, I don't have an account with
which to test more thoroughly.

I apologize for not getting to you in time for 2.0.2. Thank you for
your time and help.

C. Liu