Many sites include a root certificate in their downloaded chain. This is either a remnant of cross-root certificate mapping or a configuration error.

All tested browsers ignore the self-signed certificate as long as the same root certificate is installed in the trusted certificate store.

Unfortunately, OpenSSL, and therefore UTM, are not able to detect that the supplied root certificate is unnecessary, so the connection is blocked. Because of the significant number of sites with this configuration, it is a significant problem.

This link has an extensive discussion of the problem:

https://rt.openssl.org/Ticket/Display.html?id=3621&user=guest&pass=guest

The discussion asserts that the RFC permits inclusion of the root certificate in the downloaded chain, so it should not be considered an unforgivable error.

The last part of the discussion seems to indicate that the -trustedfirst switch in OpenSSL 1.0.2 should solve the problem, but my testing, with both 1.0.2d and 1.0.2g indicate that the problem is not solved, with or without use of any of the switches that might be relevant (-trustedfirst, -noaltchains, and -partial_chain).

I have not been able to find anything on Google to explain why the -trusted_first option does not accomplish what I want and work as documented, or even confirm that others still have this problem in version 1.0.2.

Of course, you are running OpenSSL 1.0.1 (which is not supported after 12/31/2016), and does not support the -trusted_first option at all.

Is there any hope that you can work with OpenSSL to get this addressed?

Email is a huge vector for malware. Not all of it comes in as an attachment. Links in email often lead to NEW malware. NEW versions of malware are attached or embedded into Office documents. Files users download may have NEW undetected malware in them.

Palo Alto has Wildfire. FireEye has a similar service/appliance. Each service takes URLs, Office documents and unknown files and detonates them in a sandbox to determine if they are malware. Previously unseen downloaded files are uploaded to the same service. When NEW malware or malware links are discovered, an update is pushed to all subscribing devices to block those NEW malware.

This allows for each company to help each other. I see a new threat that you have yet to see. It gets uploaded and now is defined as malware. You get the update before the file ever gets to you. And vice versa. I might have to clean up some malware, but you do not. Maybe next time you save me.

This is a huge step forward in the NGF domain.

CheckPoint goes one further and pauses the download until a determination is made. This makes it even harder for them to get your malware into your network.

I would be happy to just see the link, attachment and new downloads being detonated and email alerts being sent out. (Palo Alto style)

Mobile devices like the iPhone/iPad use HTTP range requests when accessing media content. Range requests allow a client to request a specific range of bytes from a file on the server, rather than downloading the whole file in one go.

Unfortunately downloading a file in small chunks makes it impossible to scan that file for malware. Indeed, it could provide a handy way for a malicious program or actor to circumvent gateway security measures and deliberately download malicious code.

For this reason the UTM will block range requests. The only way around this at present is to exclude the site or URL from all antivirus scanning, which potentially exposes users to malware that could have been caught if not provided in response to range requests.

It would be great to provide a way to allow range requests without exempting all HTTP traffic from a location from malware scanning. If this could be done by device type (non-mobile media players seem much less likely to use range requests) that would be super awesome.

Coming from another vendor one of the features I like/had was that I could block categories within YouTube. We are a School District that needs to access YouTube (YouTube for Education has limited content). It would be nice to setup a policy or rule to be able to block these YouTube Categories.

Currently available categories are:
• Film
• Autos
• Music
• Animals
• Sports
• Shortmov
• Travel
• Games
• Videoblog
• People
• Comedy
• Entertainment
• News
• Howto
• Education
• Tech
• Nonprofit
• Movies
• Moviesanimeanimation
• Moviesactionadventure
• Moviesclassics
• Moviescomedy
• Moviesdocumentary
• Moviesdrama
• Moviesfamily
• Moviesforeign
• Movieshorror
• Moviesscififantasy
• Moviesthriller
• Moviesshorts
• Shows
• Trailers

There could be another rule that if its not categorised then it blocks it or select an option to warn or allow.

Also perhaps the ability to change a video category like you can with domains?

https://developers.google.com/youtube/2.0/reference#YouTubeCategoryList

Reason: Google forces more and more websites to HTTPS by punishing HTTP-only sites with a bad search ranking. In such a case proxy SG only sends the auto generated certificate to the user, which results in an unclear and ugly certificate error message by the browser to the user. This can be prevented by creating a signing certificate in the internal PKI, where the proxy SG must send this signing certificate to the user. Creation of the signing certificate is out of your scope, but it will be an internal certificate, valid to the internal organization only. Sending this signing certificate to the user/browser is in your scope. Therefor this request to send the full CA chain to user/browser in case the proxy generates a certificate for a non-existing or forbidden HTTPS-site.

Remark: this request is similar to https://ideas.sophos.com/forums/17359-sg-utm/suggestions/3044210-https-scanning-have-proxy-provide-certificate-cha, but differs in 2 main aspects:
1) in our request we only request for the full CA chain when sending error messages that would otherwise invoke an invalid certificate response by the browser.
2) in our request the signing certificate is generated by an internal PKI, dedicated to the internal users only.

When using - Skip transparent mode destination hosts/nets
with Allow HTTP/S traffic for listed hosts/nets checked, not only hosts which are in Allowed Networks can reach this destination hosts. So if you have a public WLAN which is not in the Allowed Networks Web Filtering, everyone in this Network can reach the destination hosts.

The automatic Rule Allow HTTP/S traffic for listed hosts/nets should only allow the
Hosts in Allowed Networks to solve this security problem.

If you dont want to change this behavior please remove the Allow HTTP/S traffic for listed hosts/nets_ Feature for security reasons.

General firewall design:

You should include the Proxy in the network rules.

The existing design of the sophos firewall is really bad and unflexible and leads to unsecure configurations. I am sure it is much easier to use finished open source software and only create a GUI but this will be the reason why we will change to another firewall manufacturer in the future.

first i have send this to the sophos premium support.
after 18 days i got an answer i should create a feature request.