I read the document with interest and noticed there was no mention of HTTP/2 support in the XG/XGS decryption profile. What is the Sophos way forward with this protocol to improve the security scanning on the XG/XGS?
HTTP/2 and Quick etc. is of course in big interest of bigger providers like Google, Akamai etc. They want to to push this to decrease there output volume to a minumum.
In SFOS you can block QUIC and clients…
In SFOS you can block QUIC and clients will fallback to HTTP/s.
The issue with HTTP/2 is, it is rather new to begin with and there is HTTP/3 already in the pipeline. With ~45% of webservers supporting HTTP/2, it is not the best coverage. Therefore you will still have to use HTTP/1 with TLS.
HTTP/2 needs a DPI to begin with. You cannot support this protocol with a proxy based solution, as far as i understand. Therefore the Fundation is already in place with V18.0.
And HTTP/2 has only a Web based coverage. If you ignore the fact, that all other apps still use TLS, you will go blind again.
The solution would be in the current state to block HTTP/2 and fallback and use DPI to decrypt TLS1.3.
Thank you for the detailed explanation. I think there is a bit of confusion with QUIC being a udp based protocol cannot be inspected by the XG dpi engine even if using tls because from previous discussions the dpi engine cannot decrypt udp traffic.
my experience in the past says that enabling a decrypt ssl/tls rule and disabling the default breaks a lot of applications that are decrypted in the proxy.
maybe I am making a big mistake in my testing methods?
who tests all those exception sites to ensure they are save to set exceptions to scanning for, otherwise that leaves a very big security hole?ian
XG115W - v19.5.0 EAP1 - Home
If a post solves your question please use the 'Verify Answer' button.
It is always a trust relationship between the customer and the applications.
While some application simply does not work you need to exclude them from decryption. From my point of view, there is no difference in a HTTP/2 based scan engine. Its the same challenge to be able to inspect while not breaking the application.
So if you trust the publisher of the app, you can exclude them. If you do not trust or not know the application, it is better to inspect the traffic to begin with.
This is the reason, Sophos is not publishing each and every breaking App on the managed TLS exclusion list. Sophos is investing time and efforts in checking those sources and what those vendors do before placing a application on this list.
Thank you fro the update about the exclusion list.
The next question is when will the DPI engine allow the enforcement of web policies like advert blocking etc so you don't need to use the proxy?
I have been fiddling at the edges for the moment. I can setup website blocking but not application control. f you setup a firewall rule to use the DPI with allow all, does the SSL/TLS rule over ride it?
So you still need a normal firewall rule to control applications.
TLS/SSL Decryption rules are not related to anything in the system.
They simply look for encrypted traffic. If found and a decrypt rule exists, they decrypt the traffic and pass the encrypted traffic to the matching module.
So, what you are advising is I cannot use proxy web policies in ssl/tls rules and need to create new policies which appears to making like a bit difficult and duplicating efforts.
Web Filtering is targeted for HTTP and HTTPS Traffic. If DPI scans the traffic and founds HTTP/s content, it forwards it to the proxy.
Same for application control.
If you look from the outside on traffic, you basically see Port443. You cannot know, whats insight unless you decrypt the traffic. And after decryption it could be https traffic or application X/Y.
The question is, will the Firewall support HTTP/2 in the future or not?
LuCar Toni said:The solution would be in the current state to block HTTP/2 and fallback and use DPI to decrypt TLS1.3.
Didn't you meant "Block HTTP/3 (QUIC) and fall back to TLS 1.3"?
There's no good reason to block HTTP/2 at all, hence why I'm asking if it's going to be supported in the future or not.
If not, then at least warn your customers that HTTP/2 isn't supported on the Docs; Also, same with brotli compression.
Thanks for all the answers.
If a post solves your question use the 'Verify Answer' button.
XG 115w Rev.3 8GB RAM v19 MR1 @ Home.
Next silly question in the series. When I enable DPI inlet of Proxy I get warnings about some items not working, how do I tell which items will not work with DPI other then experimenting by removing one at a time?
You still need a firewall rule with application policies as well as a SSL/TLS for web policies, what order are the rules processed in?
I know you can't enable the google safe search etc what else?
About the HTTP/2 part: As far as i know, most HTTP/2 Protocols uses TLS anyways. Therefore XGS can decrypt those protocols, but cannot pass them to the proxy. In the wild, i do found plenty of HTTP/2 based operations, on firewalls, which indicates, the fallback to HTTP/1.1 works fine.
Yes, i was referring to QUIC on HTTP/3.
DPI is again a decryption on any service, seen on the firewall. Nowadays you can do this on all ports and with TLS1.3 etc. There are applications, which were designed to work without any decryption, as on that point of app creation, there was no such product of decryption.
The DPI is completely separate from the firewall stack. You can trigger decryption and a app filter. You can trigger only appfilter but no decryption. You can trigger only decryption but no app filter etc.
The DPI will take the traffic first, decrypt it and pass it to the modules to do there job.