In our list of new features:www.sophos.com/.../sophos-xg-firewall-key-new-features.pdf
Xstream ArchitectureSophos is pleased to introduce the new Xstream Architecture for XG Firewall, a new streaming packet processingarchitecture that provides extreme levels of protection and performance. The new architecture includes:
1) Xstream SSL Inspection: Organizations can enable SSL inspection on their networks withoutcompromising network performance or user experience. It delivers high-performance, high connectioncapacity support for TLS 1.3 and all modern cipher suites providing extreme SSL inspection performance across all ports, protocols, and applications. It also comes equipped with enterprise-grade controls to optimizesecurity, privacy, and performance.
2) Xstream DPI Engine: Enables comprehensive threat protection in a single high-performance streamingDPI engine with proxyless scanning of all traffic for AV, IPS, and web threats as well as providing ApplicationControl and SSL Inspection. Pattern matching on decrypted traffic makes patterns more effective and providesincreased protection from hash/pattern changing applications such as Psiphon proxy.
3) Xstream Network Flow FastPath: Provides the ultimate in performance by intelligently offloading trafficprocessing to transfer trusted traffic at wire speeds. FastPath offloading can be controlled through policy toaccelerate important cloud application traffic, or intelligently by the DPI engine based on traffic characteristics.
So what does this mean?
One of the new features that is v18.0 is a new high performance way of handling web traffic, along with new high performance way of doing SSL/TLS decryption, and a lot of new options around enforcement of TLS/SSL rules. The web proxy from 17.5 is still present, and administrators have a choice which mode they want to use.
The following is an attempt to summarize the differences between the "proxy mode" and the new "DPI mode" (Deep Packet Inspection). Basically to explain 2) and the relevant parts of 1). But the overall feature is more than what I am covering.
It focuses on differences in web for the things you could do in 17.5, and do differently in 18.0.
[deleted] - moved into top post
Thank you for the details. Can we block downloads of specific filetypes when using DPI engine? I'm not sure if this is not supported, or if I am doing something wrong.
I created a Web Policy which blocks compressed files and News sites (as a proof of concept).
I set rules such that I work using the DPI engine.
When browsing regular sites, I could browse normally (as expected).
When browsing a news site, I got blocked by being redirected to <ip>:8090 (as expected).
When downloading a zip file, the download was successful (expected/required result was that it would be blocked).
I switched to Proxy Mode, leaving everything else the same.
When browsing regular sites, I could browse normally, given I trusted the MITM certificate (as expected).
When browsing a news site, I got blocked (as expected).
When downloading a zip file, the download was blocked (as expected/required).
Hi Steven, can you please check again.
When using DPI mode, file blocks work differently because the file is delivered to the client, all but the last packet, and then scanned.
The expected result is:
Click on the zip file. The file download starts. The file download does not complete and the browser will say download failed (how this appears is browser specific).
Click on the zip file again within 2.5 minutes. The user is redirected to :8090 for a block page.
Note: filetype blocks are somewhat special in that we can sometimes block on request headers, sometimes block on the response headers, and sometimes block during the AV scan, depending on when/how we detect the restricted filetype. So the expected result can change a little.
If you want a better like-for-like comparison, go to Web > General Settings and change the AV scanning mode from Batch to Real Time. Now use the web proxy. You will get behavior that is more similar when the filetype detection happens in AV scan, though it won't make things more similar if the detection happens earlier.
Thank you Michael, in fact it was simply me failing to follow instructions as I had not set a decryption policy for the connections I was doing. In fact now that I did that, regular browsing is being inspected properly via MITM certificate.
PS/edit: quite a non-issue but when blocked by DPI, I get the following message: "... classified as Compressed%20Files." note the %20. Block message is with a space for Web Proxy filtering.