{"id":642,"date":"2017-02-24T19:27:59","date_gmt":"2017-02-24T19:27:59","guid":{"rendered":"https:\/\/i.tny.im\/?p=642"},"modified":"2017-02-24T19:28:52","modified_gmt":"2017-02-24T19:28:52","slug":"tny-network-not-affected-by-cloudflare-security-incident","status":"publish","type":"post","link":"https:\/\/i.tny.im\/?p=642","title":{"rendered":"TNY network not affected by Cloudflare security incident"},"content":{"rendered":"

A few days ago, Cloudflare reverse proxies were\u00a0found to be leaking personally-identifiable information contained in requests handled by these proxies, into the data of other requests going through them, provided these other requests met certain conditions. This information\u00a0included\u00a0cookies, passwords,\u00a0authentication tokens and encryption keys, and to make matters worse, it had already been cached by multiple systems, including Google’s web cache. See the Google’s Project Zero report<\/a>, and also Cloudflare’s blog response<\/a>. People have also\u00a0compiled lists of websites that might be affected<\/a>.<\/p>\n

We use\u00a0Cloudflare’s DNS hosting service on some of our websites. However, these\u00a0are not directly affected by this security problem, because we never used Cloudflare’s reverse proxy features<\/strong> – and, most importantly, not during the “greatest period of impact”, which according to them, was\u00a0between February 13 and February 18. Cloudflare’s DNS hosting was not affected by this issue. In addition, earlier today Cloudflare sent us an email, assuring that the domain for which we have DNS hosted by them “is not one of the domains where [they] have discovered exposed data in any third party caches”.<\/p>\n

Still, if you used your dotAccount password on any other sign-in system, we\u00a0heavily recommend that you change it immediately. Even though your password was certainly not\u00a0leaked when in transit to our websites, it could have been leaked\u00a0when signing in to other websites behind Cloudflare’s proxy service. From on now, use different passwords for each website.<\/p>\n

\n

Despite using some of Cloudflare’s services, we have always made a conscious effort to avoid their reverse proxying offers. While it is true that a large percentage of today’s web traffic goes through them, it is our understanding that the\u00a0advertised increase in website availability and speed, do not make up for the potential security troubles and the need to trust yet another party.<\/p>\n

Furthermore, a large part of the traffic handled by us, namely with the tny.im shortener, is not well-suited to caching, or would be hard to integrate with Cloudflare, to say the least. Any security or availability problem affecting Cloudflare will almost certainly affect all of the websites\u00a0that use it, as could be seen with this incident.<\/p>\n

It is also our belief that having a major portion of internet traffic going through\u00a0one same\u00a0entity poses a threat to the decentralized model of the internet, introducing a prominent single point of failure. This is true especially when said entity\u00a0sells caching and request manipulation as one of their main features (see their “ScrapeShield” feature).<\/p>\n

Their DNS hosting service was not affected by this issue, but it has had its share of availability issues in the past. We use it mainly because it is one of the few that can be controlled through an API, but we don’t need this at the moment. Migrating\u00a0to another DNS hosting service is a possibility that was already being studied before this news broke, and which will now be considered more seriously.<\/p>\n","protected":false},"excerpt":{"rendered":"

A few days ago, Cloudflare reverse proxies were\u00a0found to be leaking personally-identifiable information contained in requests handled by these proxies, into the data of other requests going through them, provided these other requests met certain conditions. This information\u00a0included\u00a0cookies, passwords,\u00a0authentication tokens and encryption keys, and to make matters worse, it had\u2026<\/p>\n

Continue reading<\/span><\/i><\/a> <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-642","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/i.tny.im\/index.php?rest_route=\/wp\/v2\/posts\/642","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/i.tny.im\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/i.tny.im\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/i.tny.im\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/i.tny.im\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=642"}],"version-history":[{"count":5,"href":"https:\/\/i.tny.im\/index.php?rest_route=\/wp\/v2\/posts\/642\/revisions"}],"predecessor-version":[{"id":647,"href":"https:\/\/i.tny.im\/index.php?rest_route=\/wp\/v2\/posts\/642\/revisions\/647"}],"wp:attachment":[{"href":"https:\/\/i.tny.im\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=642"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/i.tny.im\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=642"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/i.tny.im\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=642"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}