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

Https Strict Transport Security (HSTS) sites break transparent browser authentication

Hi,

We are evaluating transparent browser authentication with https filter only scanning.

The problem is if user opens a HSTS enabled site, chrome and firefox throws certificate errors and refuse to continue or add a security exeption. So user does not see UTM login page.

If the user opens a http or non HSTS https site first, he can login then the HSTS sites without any certificate errors.

Btw Under Web Protection->Misc->Certificate for End-User Pages ->Use a custom certificate for HTTPS pages is selected. Under there hosname is setted to artvin.edu.tr and use uploaded our wildcard valid certificate. Also in our dns server we have passthrough.artvin.edu.tr.         IN      A     213.144.15.19
So our users dont get certificate errors on passthrough.artvin.edu.tr pages.


This thread was automatically locked due to age.
  • Sorry for digging up this old topic, but we're having the same issue. Did you ever manage to do something about this?
  • One thing you can do in newer UTM releases (I'm on 9.2x) is to change the HTTPS filtering from Decrypt & Scan to URL Filtering only. If you are mainly concerned with blocking traffic to certain sites but don't need to snoop inside the https session, URL Filtering works fine with HSTS as it only looks at the requested URL (sent in the clear even on https), not the body of the request (encrypted).
  • We are indeed using URL filtering only, but I still get the HSTS error, strange.. Although I'm pretty sure I've been able to visit HSTS websites (twitter for example) before. I tried restarting web protection but that didn't help, might try to restart the whole device just to make sure..

    Update:
    Just did some testing and it seems I'm getting the HSTS error when I'm trying to visit a blocked website. We have a policy to allow social media to a limited group of users and I was testing with Twitter. When I'm in the group -> website opens fine. When I'm not in the group -> HSTS error when the proxy tries to show the "content blocked" page. IE11 still allows you to click "continue to this website" and when I do I reach the content blocked page, but with URL https://twitter.com and a certificate for twitter.com signed by the proxy.

    So even if you don't want to do HTTPS inspection, it seems you still need to fix the HTTPS certificate to enable to proxy to show a HTTPS content blocked message? Which..sucks...
  • We are indeed using URL filtering only, but I still get the HSTS error, strange.. Although I'm pretty sure I've been able to visit HSTS websites (twitter for example) before. I tried restarting web protection but that didn't help, might try to restart the whole device just to make sure..

    Update:
    Just did some testing and it seems I'm getting the HSTS error when I'm trying to visit a blocked website. We have a policy to allow social media to a limited group of users and I was testing with Twitter. When I'm in the group -> website opens fine. When I'm not in the group -> HSTS error when the proxy tries to show the "content blocked" page. IE11 still allows you to click "continue to this website" and when I do I reach the content blocked page, but with URL https://twitter.com and a certificate for twitter.com signed by the proxy.

    So even if you don't do HTTPS inspection, it seems you still need to fix the HTTPS certificate to enable to proxy to show a HTTPS content blocked message?
  • Hi icto,

    we´ve got the same issue, talked to the support yesterday. In fact, it seems to be necessary to import the utm´s ca certificate, even if you´re just doing url-filtering, but thats only necessary for sites using hsts, like "mail.google.com"... On the other websites, you can simply click the proceed button without problems. But there is also a difference between the browsers.

    Chrome and Firefox are showing a hsts error, while internet explorer shows the normal block or warning page. But take a look at the url. Chrome & Firefox redirect to https: even if you type http://gmail.com.


    So in my opinion the best way is to import the utm certificate to all the clients. And in this case, you could turn on https scanning, if you box can handle that...
  • Hi all,

    this thread could help in understanding the issue: 

    https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/t/46667

    It seems that when the action is to block, a MITM is made to show us the block page.
  • (Apologies for another necromancing of this thread)

    This issue just came up in a major way for a client with a large body of users and BYOD devices on their network which can't install the CA Certificate.

    I can confirm that even installing the proxy signing CA does not fix the HSTS issue as the connection is initiated through the proxy to the target and then is redirected by the UTM once the HTTP traffic starts. This problem occurs with URL filtering only and Decrypt and Scan. Once the user is authenticated, no problems occur but leading up to the authentication will cause a large support call overhead when users can't browse to bookface, google or hotmail (to name a few) and don't know or understand why.

    Hopefully either resolving this issue or changing the working method is on the books as HSTS will be a growing thing as it's an easy implementation for site security.
  • (Also apologies for further necromancy....)

    But I spent ages trying to get this working on a UTM SG. If you find yourself wondering how to address it, you might try creating in:

    Web Protection -> Filtering Options -> Exceptions

    New Exception:

    Tick all HTTPS Scanning options, for all requests matching these URLs:

    ^https?://([A-Za-z0-9.-]+\.)*facebook\.com/

    HTH

  • I made it working with the following settings.  Hope it can help others.

     

    Web Protection -> Filtering Options -> Exceptions

    New Exception:

    Tick all HTTPS Scanning options, for all requests matching these URLs:

    ^https?://([A-Za-z0-9.-]+\.)*google\.com/