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.
Could someone post a tutorial on how to step by step implement a DPI traffic scan? Maybe I'm doing something wrong, because after enabling "decrypt" in TLS / SSL rules some used applications stop working. They work after restarting the device, but if one of the household members leaves the house and comes back - applications cannot connect (for ex. Facebook, Facebook Messenger, Gadu Gadu Messenger, Youtube and Youtube Go App).
A brief step by step guide:
I would start by doing things incrementally, to build out knowledge and experience. By far the biggest and most common usage will be in HTTP/HTTPS so start there. Most customers will already be using the web proxy, this assumes that you have some knowledge.
Next is to determine if you are going to decrypt traffic or not. The cost and the reasons are the same as they are with the web proxy. Decrypting traffic means that you will need to deploy the appliance CA to all your devices. Regardless of whether you choose to do so in the long term, incrementally I would start by not decrypting. Make sure everything is stable without decryption before enabling.
Apply the workaround listed about so that TLS 1.3 traffic is downgraded to 1.2.
So create a a firewall rule with appropriate source and destination, service is HTTP and HTTPS. Choose a web policy, scan for malware, don't "use the web proxy".On the SSL/TLS inspection rules, just have the top two rules active. Don't create (or enable) others.
Run this for a few hours. You should see logs in the web filter log. You can test your policy works by going to HTTP and HTTPS sites that should be blocked due to category. If you do not have the CA installed, when you go to an HTTPS site that is blocked, you will first get a browser warning message. You should see in the firewall rules your new rule bandwidth goes up.
If everything is working, you can turn on HTTPS decryption. First deploy the CA to your devices.
Now you can create a SSL/TLS Inspection Rule. Use the same source and destination as your HTTPS firewall rule, HTTPS service only. Set action to decrypt. Set the profile to maximum compatibility.
Run like that for a while. See what works and what does not. If there is one particular device that is not working, check the CA on it. If there is one particular application that is not working, check the logs and see if there is anything interesting. Note what domains it is using. Some applications use their own certificate stores.
The 'just get it working' approach to HTTPS sites that don't work is to add them to the TLS exclusion list. Go to Web \ URL Groups and edit "Local TLS exclusion list" to add the domains. Then test again.Now when we (developers of this feature) find stuff that does not work, rather than adding to the exclusion list, we investigate to see why it is not working and if there is anything that the product could do differently.
OK, I already know. Not everything can be decrypted even using a certificate. Gradually, I will update individual rules as instructed, step by step.
Michael and Stuart, thank you so much for your help.
Very helpful thread guys! Thanks for all the insight into this new feature. I'm playing around with it and so far so good. Haven't encountered many issues. This seems much less intrusive than the HTTPS proxy which I had lots of issues with when trying to deploy it. It simply breaks too many things because of the full decryption and re-encryption. Xstream DPI seems much better so far.