Jump to content

Recommended Posts

Posted (edited)

Came across an issue with our current filtering solution that has an undesirable workaround. They suggest all filtering providers are the same on this issue.

 

The issue is that unless we install the Filter appliance SSL root certificate on every device, we're going to see the 'This connection is not private' error, typically in modern browsers (related to HSTS).

 

Can any other filter show a block page for HTTPS sites without needing to install the SSL certificate??

 

Smoothwall?? Sophos???

 

Basically, I'd like to take some examples back to them and suggest they are not correct in saying that all filtering engines suffer the same problem - I'm sure I've seen a block page on my device when going joining a guest network and heading to a HTTPS site (without SSL certificate) Can't remember whether it was Smoothwall or Sophos.

 

Much appreciated.

 

EDIT: Apologies, I should have mentioned that I actually don't want to SSL inspect any traffic, but without the inspection this issue is compounded in the sense that most HTTPS sites then show the 'Connection not private' problem page.

Edited by mrwoberts
Posted
Can any other filter show a block page for HTTPS sites without needing to install the SSL certificate??

 

Most filtering solutions should be able to block by domain name - so you could block the whole of, say, youtube.com - but you can't allow a domain and block specific URLs - youtube.com/videoID=123456.

Posted

If you simply want to be able to block, say, google.com, most filtering solutions will do that without SSL inspection. But, if you want to see what someone is searching for on Google? You need a certificate on every device. The domain part of a request is not itself encrypted by SSL, but the content (the full URL, the page content etc...) is.

 

I've not come across any filtering solution that can't block pages based purely on domain though!

Posted

My experience is if you are not inspecting HTTPS you get no "Connection not private" message as the certificate is untouched. You only need to install a certificate if you want to decrypt, read and then repackage the stream. This causes the "Connection not private" as something is reading the data and the browser or OS can see the certificate is different from the site. You install the certificate to say you trust things signed by this certificate so don't worry.

 

If a system is saying "Connection not private" but you are not inspecting then my suspicion would be they are decrypting the data for their own ends. We use Smoothwall and I will do some testing but have never seen a privacy issue unless we were decrypting and inspecting without installing the certificate.

 

Which system is this?

Posted
You can't downgrade https to http if hsts is enabled, so you can't show an error message. It's by design otherwise you could just show a fake copy of the page, or just downgrade attack everything and assume people won't notice.
Posted

Comments are much appreciated.

 

If I disable the SSL inspection feature, it will block the page, as expected, but for a lot of pages it shows the 'This connection is not private' page. I'm guessing that as sites enforce HTTPS, or at least have a redirect, this is causing the issue. For interest, our product is Untangle. Is anyone else using Untangle that isn't having this issue. The support at Untangle say this is normal behaviour.

@localzuk just to confirm, is the suggestion that HTTPS sites will always present the connection not private message if I don't 'inspect' the traffic?

Posted
You can't downgrade https to http if hsts is enabled, so you can't show an error message. It's by design otherwise you could just show a fake copy of the page, or just downgrade attack everything and assume people won't notice.

 

Would this then mean that all filtering providers that don't have SSL inspection enabled will present the C.N.Private page??

Posted
Even if a site enforces HTTPS it shouldn't matter because you have disabled SSL inspection so nothing should be looking at the traffic. No filter that I know of downgrades HTTPS to HTTP; they decrypt, inspect and then repackage. Either your browser/OS is being over zealous and picking up you are using a proxy and warning your users that their traffic is being monitored or your system is inspecting traffic even after you disabled it.
Posted

If we are talking specifically about block pages, i.e. when the user visits a site that is restricted by the filter, depending on how it is configured, the user will either get a connection interrupted or your connection is not private browser error instead of the intended block page if you are not intercepting SSL. This is the same for all vendors as the filter can't get into the connection to redirect it.

 

If you are talking about browsing to allowed pages on the filter, then most vendors will do filtering on domain name only if SSL inspection is not enabled.

Posted (edited)

Yes, I'm talking about blocked sites. Allowed sites all seem fine.

 

Would anyone mind just doing a check on the David's suggestion please. Could you disable inspection for a particular device then head to a site that is blocked (one that starts with HTTPS....)

 

I'd really like to know whether this is the case or not since I have assumed that the DNS lookup would trigger the block, but now I'm guessing what you're saying is that all modern browsers, Chrome/Edge/Firefox, will not permit a site to be 'redirected' from the filter??

So, if the browser asks for https://purplebricks.com, unless it receives a certificate from that site, or from the filter that is acting on behalf of that site, then you receive the CNP message??

 

So am I correct in saying that unless you bypass all your non-domain joined devices, those devices get the CNP message on blocked https sites??

Edited by mrwoberts
Posted
We only use it on the guest WiFi. We use fortinet on the main filtering solutions and this has worked wonders for years and we also use fortianalyziser to do the logging :)
  • Thanks 1
Posted

NxFilter does look interesting and I may well have a play at some point, but just wanted this paid-for solution to work properly.

@nathan3388 With Fortinet, what happens to a device that doesn't have the appliance root CA cert and you disable inspection for that device. Do blocked HTTPS sites still display the Fortinet block page??

Posted
You can set the fortigate to do https traffic inspection on guest networks if you know how the network works and can configure it. We did have this setup with a transparency proxy but we noticed that the cpu of our fortigate went through the roof. So that is why we use the nxfilter for the guest networks during the day as a basic filtering solution. If we are not using transparency proxy and just a normal rule with ssl inspection on then we have to install the ssl certificate on the device to trust the fortigate to inspect the traffic else it will throw up a certificate error. You can turn ssl inspection off but willnt filter https traffic.
Posted

The connection error is the only thing you can really expect.

 

If the browser is going to Example Domain you can replace that with a page that says "Blocked", but you can't with https because that's half point of https, the man in the middle can't change the content.

Posted
The connection error is the only thing you can really expect.

 

If the browser is going to Example Domain you can replace that with a page that says "Blocked", but you can't with https because that's half point of https, the man in the middle can't change the content.

 

Okay, thanks for that. Although, in reality I'm not asking the filter to change the content, just not allow the browser to go to the blocked site and present them with a block page. But I'm guessing therein lies the difficulty, redirecting to the block page from a HTTPS address seems to be impossible without SSL inspection, even though I don't want to inspect the page, just the address the browser wants to go to - more like URL inspection/filtering. This little test has highlighted my misunderstanding of this protocol I guess.

Posted

Would folks just mind commenting whether other Filtering solutions behave in the following way, please...

 

When SSL inspection is not enabled for a device, a blocked (https) page will present a browser error e.g. 'This connection is not Private'

 

Untangle: Yes - this is the normal response.

Sophos: ?

Smoothwall: ?

Lightspeed: ?

Fortinet: ?

iBoss: ?

NetSweeper: ?

RM SafetyNet: ?

Exa: ?

 

Any others: ?

Posted

The HTTPS block page answers are correct - when blocking an HTTPS page, filters cannot redirect to an HTTP page and show block information. The HTTPS blockpage is there so users see the actual block information and as such, the blockpage is using a certificate created by the CA on the filter - user devices needs to trust this CA in order for the certificate warnings to disappear.

 

Smoothwall have a cloud filter option on the way - currently out for Chrome and other browsers are close. This is a filtering extension that filters looking at the content coming out of the browser, not filtering the traffic sitting between the browser and the internet. With those browser extensions installing the CA is not needed but obviously won't be applicable to BYOD devices.

 

Installing the CA is easy enough once you get used to it and instructions are available from Smoothwall and other vendors.

  • Thanks 1
Posted
Would folks just mind commenting whether other Filtering solutions behave in the following way, please...

When SSL inspection is not enabled for a device, a blocked (https) page will present a browser error e.g. 'This connection is not Private'

 

Yes to all, because that's how HTTPS works. Unless you have the CA that is being used to sign the block page installed as trusted on the client, you will receive a browser error as it doesn't trust that page. Unless, of course, your block page is on domain which has a commercial SSL certificate signing it.

  • Thanks 1
Posted
Yes to all, because that's how HTTPS works. Unless you have the CA that is being used to sign the block page installed as trusted on the client, you will receive a browser error as it doesn't trust that page. Unless, of course, your block page is on domain which has a commercial SSL certificate signing it.

 

Looks like I'm heading down the certificate (and captive portal) route.

 

Thanks again for replies.

Posted (edited)
@mrwoberts look at transparent proxies this will inspect the https webpage and if on the filtering list block it without installing a SSL on any device that the organisation doesn't not belong to Edited by nathan3388

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...