Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 15 subscribers
  • Views 2976 views
  • Users 0 members are here
Options
Suggested
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

No block pages being displayed when sites not allowed just https error page

Brian Straka

Hi,

I have enabled blocking webmail from the endpoint agent through a web control policy.  When a user attempts to go to gmail or hotmail they get an SSL error in their browser rather than a sophos block page or some sort.  How can I fix this to give the end user a meaningful error that does not look like something is broken but rather that what they are attempting to do is disabled by admin and not allowed via company policy?



This thread was automatically locked due to age.
Parents
  • 0

    The current web protection/control component at the endpoint only replaces the page for HTTP traffic as it doesn't do any man-in-the-middle for HTTPS.  For HTTPS, the domain name being accessed is obtained from SNI record in the handshake and used for the cloud lookups.  This result s used as the basis for the allow/block action. Without this inspection, it's not possible to inject a replacement page,

    As far as I understand it, there is a new endpoint web protection feature being developed which is due to go into an EAP reasonable soon.  That will have full SSL inspection and then will be able to present a block/warn page for HTTPS in the browser.

    The XG firewall can man-in-the-middle HTTPS traffic and can therefore present the user with in browser messaging.

    It is a little tricky even then, you might have a domain good.com, which is responsible for all the content, apart from one URL which presents say a banner add. If you block that one banner image from being fetched, would you want to replace then entire page with a block or just prevent an image loading for the add.  In this case it feels like a silent block for that one main resource is the right thing to do,  Of course there is quite a spectrum of use cases for that.

    Hope it helps.

Reply
  • 0

    The current web protection/control component at the endpoint only replaces the page for HTTP traffic as it doesn't do any man-in-the-middle for HTTPS.  For HTTPS, the domain name being accessed is obtained from SNI record in the handshake and used for the cloud lookups.  This result s used as the basis for the allow/block action. Without this inspection, it's not possible to inject a replacement page,

    As far as I understand it, there is a new endpoint web protection feature being developed which is due to go into an EAP reasonable soon.  That will have full SSL inspection and then will be able to present a block/warn page for HTTPS in the browser.

    The XG firewall can man-in-the-middle HTTPS traffic and can therefore present the user with in browser messaging.

    It is a little tricky even then, you might have a domain good.com, which is responsible for all the content, apart from one URL which presents say a banner add. If you block that one banner image from being fetched, would you want to replace then entire page with a block or just prevent an image loading for the add.  In this case it feels like a silent block for that one main resource is the right thing to do,  Of course there is quite a spectrum of use cases for that.

    Hope it helps.

Children
Unfiltered HTML