We have just released the latest version of our core web filtering appliance - version 2.0.10 of the R3000. General availability of the patch is set for January 7th, but you can contact Tech Support and request it today if you like. We’re going GA after the Holidays to reduce the load on Tech Support, which always sees a spike in activity after a major patch release (despite our best efforts).

There is lots of great stuff in this release. However, in this post I’m going to focus on the changes that affect how we handle proxies: improvements in our HTTPS filtering and pattern-based blocking. I’m going to cover:

• Block page on a pattern block
• New options that enhance HTTPS Medium and tame HTTPS High
• Whitelist feature for pattern detection

Let’s take a look at the details.

Block page on a pattern block

We’ve fixed one of the most confusing aspects of the product when it comes to figuring out whether or not our proxy pattern blocking is working. In previous versions of the filter, we would simply send a TCP reset back to the browser, which makes the user (or admin testing our product) think a network error occurred. Now, we’ll actually show a block page. The details, including screen shots, can be found in this previous post.

New options that enhance HTTPS Medium and tame HTTPS High

As you know, HTTPS filtering is an important part of blocking web-based proxies. Many web-based proxies specifically use HTTPS because they know that not everybody is filtering HTTPS. This previous post provides an overview of that problem.

HTTPS filtering options on the R3000 are controlled globally from the System tab –> Control page –> HTTPS filtering section. There are four options: None, Low, Medium and High. None is obvious - it tells the filter to ignore HTTPS. The other three settings tell the filter to look more and more closely at the underlying SSL connection, including using certificate and connection heuristics.

Unfortunately, what we’ve found is that the most optimal set of heuristics exists somewhere in between Medium and High. Medium provides good coverage but lets some badly behaving SSL sites (which many proxies are) to get through, and High blocks all that stuff but some legitimate things too.

[Note: I'm being vague here because we consider the specifics of the implementation to be proprietary information. If you're a customer, feel free to email me or Tech Support and we'll be happy to explain it in depth.]

So, we’ve added a few new options to let you tweak Medium to be a little more restrictive and tweak High to be a little less restrictive, at your discretion. Both options default to on, so if you’re already at those HTTPS filtering settings, you’re going to get the improved functionality by default. We added them as options so that you could go back to legacy behavior if you needed to.

My advice is to use HTTPS-Medium with the new option on.

Here’s a screenshot of the Medium option:

Here’s a screenshot of the High option:

Whitelist feature for pattern detection

Like all signature-based security schemes, our pattern detection periodically blocks things in error — aka “false positives”, or what we call an “overblock”. In the past, when a customer reported overblocking due to a pattern, there were only two options to solve the problem: (1) turn off pattern detection and suffer until we released a fix, or (2) live with the overblock and suffer until we released a fix.

Sometimes it takes time for us to get a fix out. Like all good software engineering organizations, we go through a strict process for releasing code (including patterns) to all of our customers. We run it through QA, performance testing and a Beta test cycle. The turn around on this can often be measured in weeks.

So we’ve added a whitelist, editable from the backend by Tech Support, so that there’s now a third option when you experience an overblock: (3) whitelist the site that’s being blocked in error, leave pattern detection on, and live happily until we release a fix.

There are plenty of other great features in this release. You can read about in the documentation or the release notes. I’ll almost certainly cover some of them in future blog posts. They include:

• Secure login enhancements, specifically for complying with government standards
• Pattern detection for any category. We’re currently working on:
  • Games patterns for apps like World of Warcraft and Second Life, and
  • Streaming Media patterns to selectively block video embedded in sites.

Finally, I want to bring up one change that may have some effect on performance. We used to allow you to selectively turn pattern detection on for IM, proxies and P2P. Now it’s all grouped into a single Pattern blocking checkbox. This can be found on the System tab –> Control page –> Service Control section, just below the HTTPS filtering options. (See the screenshots above.) We did this to accommodate the feature that extends pattern detection to any category.

In some larger environments, especially on older appliances with slower hardware, you may have disabled one of the pattern detection categories for performance reasons. We can still accommodate this configuration, but it requires a call to Tech Support and a backend change.

Tags: patterns, Proxies, R3000

This entry was posted on Thursday, December 27th, 2007 at 10:51 am and is filed under Product Stuff, Proxies. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.