Photo by Liu Zai Hou / Unsplash

In Q2, Cloudflare released several products which enable a better Internet “end-to-end” — from the mobile client to host infrastructure. Now, anyone from an individual developer to large companies and governments, can control, secure, and accelerate their applications from the “perimeter” back to the “host.”

On the client side, Cloudflare’s Mobile SDK extends control directly into your mobile apps, providing visibility into application performance and load times across any global carrier network.

On the host side, Cloudflare Workers lets companies move workloads from their host to the Cloudflare Network, reducing infrastructure costs and speeding up the user experience. Argo Tunnel lets you securely connect your host directly to a Cloudflare data center. If your host infrastructure is running other TCP services besides HTTP(S), you can now protect it with Cloudflare’s DDoS protection using Spectrum.

So for end-to-end control that is easy and fast to deploy, these recent products are all incredible “workers” across the “spectrum” of your needs.

End users want richer experiences, such as more video, interactivity, and images. Meeting those needs can incur real costs in bandwidth, hardware, and time. Cloudflare addresses these with three products that improve video delivery, reduce paint times, and shrink the round-trip times.

Cloudflare now simplifies and reduces delivery cost of video with Stream Delivery. Pages using plenty of Javascript now have faster paint times and wider mobile-device support with Rocket Loader. If you’re managing multiple origins and want to ensure fastest delivery based on the shortest round-trip time, Cloudflare Load Balancer now supports Dynamic Steering.

Attackers are shifting their focus to the application layer. Some security features, like CAPTCHA and Javascript Challenge, give you more control and reduce false-positives when blocking rate-based threats at the edge, such as layer 7 DDoS or brute-force attacks.

Finally, Cloudflare extended privacy to consumers through the launch of our DNS resolver 1.1.1.1 on 4/1/2018! Now users who set their DNS resolvers to 1.1.1.1 can browse faster while protecting browser data with Cloudflare’s privacy-first consumer DNS service.

Tue, July 10, 2018Dynamic steering is a load balancing feature that automates traffic steering across origins in multiple geographic regions. Round-trip time (RTT) for health checks is calculated across multiple pools of load balanced servers and origins to determine the fastest server pools. This RTT data enables the load balancers to identify the fastest pools, and to direct user requests to the most responsive origins.

• Blog Post

• Product Page

• Support Article

Thu, July 5, 2018Cloudflare's Authoritative DNS now supports the following record types: CERT, DNSKEY, DS, NAPTR, SMIMEA, SSHFP, TLSA, and URI via the web and API.

Mon, June 11, 2018The Developer Portal has been updated in Q2 to include improved search, documentation for new products, and listings of upcoming Cloudflare community events.

• Developer Portal

Fri, June 1, 2018Rocket Loader has been updated to deliver faster performance for website paint & load times by prioritizing website content over JavaScript. Majority of mobile devices are now supported. Increased compliance with strict content security policies.

• Support

• Blog

Thu, May 31, 2018Cloudflare’s Stream Delivery solution offers fast caching and delivery of video content across our network of 150+ global data centers.

• Product Page

Tue, May 29, 2018On June 4, Cloudflare will be dropping support for TLS 1.0 and 1.1 on api.cloudflare.com. Additionally, the dashboard will be moved from www.cloudflare.com/a to dash.cloudflare.com and will require a browser that supports TLS 1.2 or higher.

• Product Page

• Blog Post

Mon, May 21, 2018Rate Limiting has two new features: challenges (CAPTCHA and JS Challenge) as an Action; and matching Header attributes in the response (from either origin or the cache) as the Trigger. These features give more control over how Cloudflare Rate Limiting responds to threshold violations, giving customers granularity over the types of requests to "count" to fit their different applications. To learn more, go to the blog post.

• Product Page

• Blog Post

Thu, May 10, 2018The Cache-Tag header now supports up to 1000 tags and a total header length of 16kb. This update simplifies file purges for customers who deploy websites with Drupal.

• Support article

Wed, May 2, 2018Starting May 2 2018, users can go to the new home of Cloudflare’s Dashboard at dash.cloudflare.com and share account access. This has been supported at our Enterprise level of service, but is now being extended to all customers.

• Blog Post

Thu, April 12, 2018Cloudflare is now able to validate origin certificates that use a hostname's CNAME target in Full SSL (Strict) mode. Previously, Cloudflare would not validate any certificate without a direct match of the HTTP hostname and the certificate's Common Name or SAN. This update allows SSL for SaaS customers to more easily enable end-to-end security.

• Support

• SSL for SaaS

Thu, April 12, 2018Spectrum protects TCP applications and ports from volumetric DDoS attacks and data theft by proxying non-web traffic through Cloudflare’s Anycast network.

• Product Page

• Blog Post

Wed, April 11, 2018Cloudflare workers can now control cache TTL by response code. This provides greater control over cached assets with Cloudflare Workers.

• Documentation

Thu, April 5, 2018Argo Tunnel ensures that no visitor or attacker can reach your web server unless they first pass through Cloudflare. Using a lightweight agent installed on your origin, Cloudflare creates an encrypted tunnel between your host infrastructure and our nearest data centers without opening a public inbound port. It’s more secure, more performant, and easier to manage than exposing your services publically.

• Developer Doc

• Read More

CC-BY 2.0 image by Benjamin Child

Rate Limiting is one more feature in our arsenal of tools that help to protect our customers against denial-of-service attacks, brute-force password attempts, and other types of abusive behavior targeting the application layer. Application layer attacks are usually a barrage of HTTP/S requests which may look like they originate from real users, but are typically generated by machines (or bots). As a result, application layer attacks are often harder to detect and can more easily bring down a site, application, or API. Rate Limiting complements our existing DDoS protection services by providing control and insight into Layer 7 DDoS attacks.

Rate Limiting is now available to all customers across all plans as an optional paid feature. The first 10,000 qualifying requests are free, which allows customers to start using the feature without any cost .

Over the past few months, Cloudflare customers ranging from e-commerce companies to high-profile, ad-driven platforms have been using this service to mitigate malicious attacks. It made a big difference to their business: they’ve stopped revenue loss, reduced infrastructure costs, and protected valuable information, such as intellectual property and/or customer data.

Several common themes have emerged for customers who have been successfully using Rate Limiting during the past couple months. The following are examples of some of the issues those customers have faced and how Rate Limiting addressed them.

Buycraft, a Minecraft e-commerce platform, was subjected to denial-of-service attacks which could have brought down the e-commerce stores of its 500,000+ customers. Rate Limiting addresses this common attack type by blocking offending IP addresses at its network edge, so the malicious traffic doesn’t reach the origin servers and impact customers.

Haveibeenpwned.com provides an API that surfaces accounts that have been hacked to help potential victims identify whether their credentials have been compromised. Troy Hunt (the service’s creator), decided to use Cloudflare’s Rate Limiting to protect his API from malicious traffic, leading to improved performance and reduced infrastructure costs.

After IT consulting firm 2600 Solutions, which manages Wordpress sites for clients, was brute-forced over 200 times in a month, owner Jeff Williams decided to use Cloudflare Rate Limiting. By blocking excessive failed login attempts, they were able to not only protect their clients’ sites from being compromised, they also ensured legitimate users were not impacted by slower application performance.

Another Cloudflare customer saw valuable content being scraped from their site by competitors using bots. Competitors then used this scraped content to boost their own search engine ranking at the expense of the targeted site. Our customer lost tens of thousands of dollars before using Cloudflare’s Rate Limiting to prevent the bots from scraping content.

Anyone can start utilizing the benefits of Cloudflare’s Rate Limiting. With the Cloudflare Dashboard, go to the Firewall tab, and within the Rate Limiting card, click on “Enable Rate Limiting.”

Even though you will be prompted to enter a payment method to start using the service, you will not be charged for the first 10,000 qualifying requests. Once done, you’ll be able to create rules.

If you are on an Enterprise plan, contact your Cloudflare Customer Success Manager to enable Rate Limiting.

As customers begin to understand attack patterns and their own application’s potential vulnerabilities, they can tighten criteria. All customers can create path-specific rules, using wildcards (for example: www.example.com/login/\* or www.example.com/\*/checkout.php). Customers on a Business or higher plan can specify to rate limit only certain HTTP request methods.

Customers on the Pro and higher plans will be able to ‘simulate’ rules. A rule in simulate mode will not actually block malicious traffic, but will allow you to understand what traffic will be blocked if you were to setup a ‘live’ rule. All Customers will have analytics (coming soon) to let them gain insights into the traffic patterns to their site, and the efficacy of their rules.

• If you haven’t enabled Rate Limiting yet, go to the Firewall App and enable Rate Limiting

• Create your first rule

• For more information, including a demo of Rate Limiting in action, visit www.cloudflare.com/rate-limiting/.

CC BY 2.0 image by Brian Hefele

Rate Limiting allows a customer to rate limit, shape or block traffic based on the rate of requests per client IP address, cookie, authentication token, or other attributes of the request. Traffic can be controlled on a per-URI (with wildcards for greater flexibility) basis giving pinpoint control over a website, application, or API.

Cloudflare has been dogfooding Rate Limiting to add more granular controls against Layer 7 DOS and brute-force attacks. For example, we've experienced attacks on cloudflare.com from more than 4,000 IP addresses sending 600,000+ requests in 5 minutes to the same URL but with random parameters. These types of attacks send large volumes of HTTP requests intended to bring down our site or to crack login passwords.

Rate Limiting protects websites and APIs from similar types of bad traffic. By leveraging our massive network, we are able to process and enforce rate limiting near the client, shielding the customer's application from unnecessary load.

To make this more concrete, let's look at a live demonstration rule for cloudflare.com. Multiple rules may be used and combined to great effect -- this is just a limited example.

Read on, and then test it yourself.

Imagine an endpoint that is resource intensive. To maintain availability, we want to protect it from high-volume request rates - like those from an aggressive bot or attacker.

URL *.cloudflare.com/rate-limit-test

Rate Limiting allows for * wildcards to give more flexibility. An API with multiple endpoints might use a pattern of api.example.com/v2/*

With that pattern, all resources under /v2 would be protected by the same rule.

ThresholdWe set this demonstration rule to 10 requests per minute, which is too sensitive for a real web application, but allows a curious user refreshing their browser ten times to see Rate Limiting in action.

ActionWe set this value to block which means that once an IP addresses triggers a rule, all traffic from that IP address will be blocked at the edge and served with a default 429 HTTP error code.

Other possible choices include simulate which means no action taken, but analytics would indicate which requests would have been mitigated to help customers evaluate the potential impact of a given rule.

Timeout

This is the duration of the mitigation once the rule has been triggered. In this example, an offending IP address will be blocked for 1 minute.

Response body type

This type was set to HTML in the demo so that Rate Limiting returns a web page to mitigated requests. For an API endpoint, the response body type could return JSON.

Response body

The response body can be anything you want. Refresh the link below 10 times very quickly to see our choice for this demonstration rule.

https://www.cloudflare.com/rate-limit-test

We could have specified a Method. If we only cared to rate limit POST requests, we could adjust the rule to do so. This rule could be used for a login page where high frequency of POSTs by the same IP is potentially suspicious.

We also could have specified a Response Code. If we only wanted to rate limit IPs which were consistently failing to authenticate, we could create the rule to trigger only after a certain threshold of 403’s have been served. Once an IP is flagged, perhaps because it was pounding a login endpoint with incorrect credentials, that client IP could be blocked from hitting either that endpoint or the whole site.

We will expand the matching criteria, such as adding headers or cookies. We will also extend the mitigation options to include CAPTCHA or other challenges. This will give our users even more flexibility and power to protect their websites and API endpoints.

We'd love to have you try Rate Limiting. Read more and sign up for Early Access.

**Note: This post was updated 4/13/17 to reflect the current product name. All references to Traffic Control have been changed to Rate Limiting.*

By analyzing the user agent strings of requests passing through the CloudFlare network, we were able to piece together a pretty good picture of iOS 9 uptake. Here’s an hour-by-hour look at requests from iOS 8 devices (blue) and iOS 9 devices (orange) for the first 24 hours after the announcement.

We started seeing small amounts of iOS 9 usage before it was officially released, followed by a spike immediately after the launch (times are shown in UTC, so the 10:00AM announcement shows up as hour 18). You can also see a second spike at 10:00 UTC when Europe started waking up.

Even though the official release was for iOS 9.0, we also found beta iOS 9.1 in the wild. Curious about the comparative traffic between the two?

iOS 9.0 is shown in blue, while 9.1 is shown in orange. As you can see, 9.0 adoption exploded after Apple’s official launch, while the 9.1 beta requests remained steady.

Fast-forward five days, and it’s clear that iOS 9 adoption didn’t slow down after the launch. As of September 21st, the relative traffic of iOS 9 (orange) to iOS 8 (blue) on the CloudFlare network is around 30-35%.

A key part of the iOS 9 announcement was that all iOS apps running on 9.0+ will require IPv6 support. The IPv4 address space is nearly exhausted, and switching to IPv6 is the only way to keep adding more devices to the global Internet.

iOS 9’s IPv6 requirement compliments CloudFlare’s mission to make a better Internet. We’ve been doing our part to encourage IPv6 adoption by providing free IPv6 support to all web properties on our network.

Although it’s still pretty early, we can already see an uptick in IPv6 requests due to iOS 9:

The first chart shows the number of IPv4 vs. IPv6 requests for iOS 8, while the second shows iOS 9. Even after only a few days, we’re seeing a 1.07% increase in IPv6 requests thanks to iOS 9.

Seeing over 5% of global Internet requests gives us an interesting perspective on current events. We get to watch the worldwide impact of everything from product launches like iOS 9 to hiccups in the Internet infrastructure like the Dyn outage of last July and even governments turning off the Internet. We try our best to use our unique vantage point to better the Internet as a whole and raise awareness for critical technologies like IPv6.