This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Certificate for Sophos Web Protection Warnings?

Hello,

I need to reopen the question from an older "comment" by Robert, seen here:
(https://community.sophos.com/intercept-x-endpoint/f/discussions/122473/certificate-for-sophos-web-protection-warnings)

As most of the web is ssl by now, a lot of our users continously raise tickets about ssl errors, as they don't see, that the site is blocked by sophos/design/management request.

Expected behaviour:
* User must be made aware of that the site is blocked through web control/sophos and not because of some ssl error

This for sure can be achived by sticking a CA Certificate in AD or by some kind of popup through the sophos client or something else. It used to work onsite (UTM) with pushing an additional CA cert out to the clients, but we are certainly open for other solutions.

Please provide any solutions besides switching the software?



This thread was automatically locked due to age.
Parents
  • Hello Sophos ma-edv,

    Thank you for reaching out to the Sophos Community. Sorry to inform you that with Sophos Endpoint's Web Control components as they are right now, it is not possible to display the "Website Blocked" page for HTTPS sites.

    With HTTP traffic this is possible as the connection is not secured. Sophos' Web Control components can inject the "Blocked" webpage into the HTTP traffic so that the message is displayed to inform the end-user that the page was blocked. For HTTPS traffic, as the traffic is secured, this is not possible to do. 

    The UTM or XG are able to perform this operation differently. The network appliances do not need to inject the webpage into the traffic, the appliances will instead perform a redirect to their own secured webpage instead of returning the original traffic that was destined for the endpoint. You can picture this as the endpoint connecting to the UTM/XG's webpage displaying a "Block" message. 

    If you would like to see changes made to Sophos AV going forward so that Web Control behaves more similarly to the XG or UTM I recommend submitting your vote on the following feature request.
    https://ideas.sophos.com/forums/285723-endpoint-protection/suggestions/18971314-block-page-notice-for-https-content

    The following article does a great job of explaining the mechanisms at play in terms of how the XG handles this. You'll find that there is much that needs to be present on the network appliance in terms of how it handles these connections in order to present the block message.  
    https://support.sophos.com/support/s/article/KB-000038420?language=en_US

    Kushal Lakhan
    Team Lead, Global Community Support
    Connect with Sophos Support, get alerted, and be informed.
    If a post solves your question, please use the "Verify Answer" button.
    The New Home of Sophos Support Videos!  Visit Sophos Techvids
Reply
  • Hello Sophos ma-edv,

    Thank you for reaching out to the Sophos Community. Sorry to inform you that with Sophos Endpoint's Web Control components as they are right now, it is not possible to display the "Website Blocked" page for HTTPS sites.

    With HTTP traffic this is possible as the connection is not secured. Sophos' Web Control components can inject the "Blocked" webpage into the HTTP traffic so that the message is displayed to inform the end-user that the page was blocked. For HTTPS traffic, as the traffic is secured, this is not possible to do. 

    The UTM or XG are able to perform this operation differently. The network appliances do not need to inject the webpage into the traffic, the appliances will instead perform a redirect to their own secured webpage instead of returning the original traffic that was destined for the endpoint. You can picture this as the endpoint connecting to the UTM/XG's webpage displaying a "Block" message. 

    If you would like to see changes made to Sophos AV going forward so that Web Control behaves more similarly to the XG or UTM I recommend submitting your vote on the following feature request.
    https://ideas.sophos.com/forums/285723-endpoint-protection/suggestions/18971314-block-page-notice-for-https-content

    The following article does a great job of explaining the mechanisms at play in terms of how the XG handles this. You'll find that there is much that needs to be present on the network appliance in terms of how it handles these connections in order to present the block message.  
    https://support.sophos.com/support/s/article/KB-000038420?language=en_US

    Kushal Lakhan
    Team Lead, Global Community Support
    Connect with Sophos Support, get alerted, and be informed.
    If a post solves your question, please use the "Verify Answer" button.
    The New Home of Sophos Support Videos!  Visit Sophos Techvids
Children
  • Thank you very much for the response. I am a still surprised to understand that such an obvious thing seems to require a user-based-feature request. To be honest -especially after your answer - I am not fully convinced that SOPHOS product management has the same level and quality of understanding than the technical support & field engineers do.

    You're absolutly right about the complex issues arrising from the challenge to display some kind of error message WITHIN the browser. Here you have all the issues with HTTPS traffic, CA and such.

    Anyhow - as we are speaking about Sophos Central - and a windows only environment - THERE IS an Sophos application icon running in the tray. And as this application is intercepting the traffic, it would be for sure capable of displaying some kind of information to the user.

    Maybe I am missing something, as I see popup messages in the screen o this KB entry.
    https://support.sophos.com/support/s/article/KB-000035134?language=en_US


    But I have no clue, how to enable those popup messages within Sophos Central Endpoint Protection.. Any hints?

  • Hello ma-edv,

    this article is for the (near EOL) on-premise SESC. This behaviour has been removed from the Central version, the explanation is in the last paragraph of Rich Baldry's comment.

    Christian