SSL Inspector rules effectiveness question

[AdamLucasReed]

I have a key question about the functionality of the SSL Inspector app and the default rule set.

What we don’t understand is why the default inspection rules list what we would have thought as trusted locations, i.e google.com, yahoo.com etc. Would not disguised SSL attacks be coming from less reputable / niche url locations ?

I do see a “Inspect all Traffic” rule, but having watched the Tech Talk webinar, it is advised not to enable this rule due to various technical restrictions opposed by how Google / Chrome certificates work. This seems at odds with what I understand the SSL Inspector sets out to achieve. A counter point to this Google specific rationale for omitting a scan all rule is that the default rules do actually include a Google inspection rule.

As a consequence it appears that we have to add SSL rules for every single site to inspect manually which is is not viable considering the scope of legitimate sites visited by users on the network (not to mention the worst case scenarios of malicious or improper usage).

With the above in mind, it is almost sensible that we don’t need to set this up.

Any advice / recommendations on the use-case and configuration of the SSL Inspector app would be greatly appreciated.
Cheers,
Adam.

[dmorris]

Different approaches are described here.
https://wiki.untangle.com/index.php/HTTPS

What are your goals? Why do you want to SSL inspect at all?

[miles267]

I tried to use SSL Inspection both on Sophos’s UTM and Untangle. Unfortunately found it tedious. am sure there are many more versed in how to make it work effectively. I just found myself having to make exceptions for sites constantly.


Sent from my iPhone using Tapatalk

[AdamLucasReed]

Thanks for your reply.

Goals: Provide the most secure possible network protection for a small business studio environment.

Why SSL: A large portion of the network traffic is SSL. If just reliant on Web Filter (without SSL) any site that has been compromised is not scanned for threats or violations of security policy, likewise any site not previously indexed on the ban list can actively be sending malicious content masked by SSL. Untangle technical advice highlights this issue.

The ambiguity of your response highlights our query of what is the point of adding SSL if it is just for known sites particularly those that would have extremely high security.

Niche url sites, which are typically legitimate browsing destinations, are the sites that we would feel is where hijack threats would be coming from, including masked threats over SSL. This is not to mention the concerns regarding the more malicious user who is masking their activity simply by doing it over SSL.

[dmorris]

To be blunt, I don't think SSL Inspection is going to help you improve your security posture.

Web Filter already blocks malicious sites (based on cert/SNI). The only thing you would gain is inspection of the actual content (like for Virus Blocker) but those benefits won't compare to the huge headaches of doing SSL Inspection on all SSL traffic.
Typically SSL Inspection will be used in environments where all the endpoints are controlled (easier to deal with CA installation) and there is a specific need to control content on the network, like schools.

more info here: https://www.untangle.com/inside-unta...o-content-era/

[AdamLucasReed]

Thanks for the link.
It is great to have the honest "gotcha" caveats.

We are still left in a position of continued ambiguity about our own situation, considering our environment is NOT a BYOD environment, and any applications that don't trust the root CA may be added to the exceptions, do you not see that it would be viable and productive to turn it on? Obviously we do not want to turn it on if it really is pointless for us, so the real world advice about us doing it would be greatly appreciated.

[dmorris]

It depends.
Whether or not its worth it to you depends on how much you value content-scanning vs the time you spend on SSL inspection headaches.

What kind of clients are you running? Do you have some sort of update policy for them? Do they have AV?

Like I said, in most cases I don't think it noticeably improves your security posture because you already have malware blocking. All you gain with ssl inspection is content inspection from trusted content sites (google, dropbox, etc). However if you have a clean environment (no byod and have some automated way to push out the CA like group policies) then SSL inspection can actually be pretty smooth. Its when you start throwing in wildly heterogeneous environments that its a pain.

The common use case we see for SSL inspection is content control, not security, because in some of those cases it is required and there is no way around doing it.

[TheDude]

It depends.
Whether or not its worth it to you depends on how much you value content-scanning vs the time you spend on SSL inspection headaches.

What kind of clients are you running? Do you have some sort of update policy for them? Do they have AV?

Like I said, in most cases I don't think it noticeably improves your security posture because you already have malware blocking. All you gain with ssl inspection is content inspection from trusted content sites (google, dropbox, etc). However if you have a clean environment (no byod and have some automated way to push out the CA like group policies) then SSL inspection can actually be pretty smooth. Its when you start throwing in wildly heterogeneous environments that its a pain.

The common use case we see for SSL inspection is content control, not security, because in some of those cases it is required and there is no way around doing it.

I have yet to find ssl inspection to be a smooth process regardless of how you distribute the certificate especially for current android devices.

The nice thing about inspection is being able to see the data - eg google search queries etc. or any other data you want to capture and be able to review. Google being one of the most important ones.

I have beat this to death without any response from untangle and was hoping you could shed some light on it. Android 7+ devices will not even pass a connectivity check when connecting to the network with inspection on. I have spent a lot of time adding exception rules with no luck. I get that there are hard coded certificates per app etc but is there no way to only inspect search traffic and bypass the rest?

Also, I could totally be missing something here but is there not a way to determine exactly what domain the abandoned errors pertain to so you can allow those specific ones? All I can see is an IP address. Do a nslookup and allow that domain, then it changes. It is a cat and mouse game. Is there not a better way to approach this?

I understand that inspection does not provide any additional security but certainly is necessary if you want to monitor the content of your traffic. Any help or insight into this would be really appreciated!

[dmorris]

When I said "clean environment" I did not mean android.

Android is difficult (as discussed in the article linked above) and I suspect it will continue to get more difficult as time moves on.

Automatically using abandon is an interesting idea, but would also provide the client a trivial way to escape ssl inspection. Although you could argue you don't care in some cases because you know/trust the client.

[TheDude]

When I said "clean environment" I did not mean android.

Android is difficult (as discussed in the article linked above) and I suspect it will continue to get more difficult as time moves on.

Automatically using abandon is an interesting idea, but would also provide the client a trivial way to escape ssl inspection. Although you could argue you don't care in some cases because you know/trust the client.

Good article but sad news

I agree with a free and open internet but on the other hand if you are on my network you should have to comply with my policy or stay off. This gives end users the ability to evade the policy essentially. Which makes me wonder, who is trusted then? If nobody is able to inspect the traffic to identify threats then how would one ever know if a trusted source becomes sketchy? I mean, I trust someone until I don't. Once I have reason to no longer trust them it's game over, this eliminates the ability to audit the trust. I know this has nothing to do with Untangle, I am just spitballing here.

This seems especially frustrating for the enterprise environment. It leaves you with only one option. Either allow it or block it entirely. Thats a bummer on a big scale. One would think that google would allow for admins to set a device policy that would permit self signed certs while also redirecting pinned certs to the device ca store when said policy is in place... I know this would not provide a solution for BYOD but you can always place them on a seperate vlan with their own policy etc... Again, just thinking out loud here

As far as untangle goes, it would be AWESOME if we could set a flag in the inspection rule to log but allow abandoned certs per rule. This would give us the benefit of inspecting what we can but allowing the rest to flow unimpeded and logged for analysis at a later time. I get that there is some traffic we will not be able to inspect but inspecting nothing because its a pain in the butt to manage does not really seem like a good approach either. It would also make following the path of the abandoned errors easier as one normally leads to more. lol, while I am in suggestion mode... It would also be great to have the exact abandoned domain in the log so we don't have to do nslookups on them all I think if SSL inspection had just a few improvements that automated some of the admin tasks and streamlined the process a bit you would see many more people turn it back on!

Thanks for listening to me ramble, hopefully these seem like reasonable suggestions.