https inspection - decrypt and scan using public cert?

No.  What you are doing with HTTPS scanning is telling clients that the proxy certificate issued by the proxy CA is valid for all sites.  You would not get a valid public certificate from a CA that does this (or at least I certainly hope not).  For mobile devices, you can typically visit hxxp://passthrough.fw-notify.net/cacert.pem and it should prompt clients to install the certificate.  I am not aware of a automated way to do this via android clients though.

Louis,

In HTTPS Decrypt and Scan, the UTM is conducting a man-in-the-middle attack.  There should be no way to get around this by using another certificate.   If there is, then what's the point of having the UTM or activating HTTPS scanning?  The only way one would bypass HTTPS scanning is to go out through another protocol on another port or bypass UTM altogether and go out through another route.

Unless you have an MDM (Sophos Mobile, VMWare AirWatch, ManageEngine, etc) that can mass-deploy certificates to all your various Android devices, I don't know of any other way update a group of Android devices at once.  Some MDMs can mass-deploy certificates and security settings to computers and other devices as well, giving you an all-in-one deployment platform.

As they have said, a root certificate makes you a CA.  Consequently, you cannot buy a root certificate.  You would have to buy the company, and then abide by CA regulations.

I favor https scanning, but it is controversial exactly because it uses a bit of corporate-sanctioned misrepresentation to do what https is intended to prevent - eavesdropping.

DouglasFoster said:

As they have said, a root certificate makes you a CA.  Consequently, you cannot buy a root certificate.  You would have to buy the company, and then abide by CA regulations.

I favor https scanning, but it is controversial exactly because it uses a bit of corporate-sanctioned misrepresentation to do what https is intended to prevent - eavesdropping. 

Douglas,

I agree.  It's a double edged sword.  Most Guest Wi-Fi is not covered by Decrypt and Scan in order to prevent accidental breaches of Banking/PCI, Privacy and other similar laws/requirements/agreements.  On the other hand this lack of scanning is also part of what makes Guest Wi-Fi untrustworthy.

If you are using UTM to protect both Guest WiFi and internal users, you need to be careful that you do not accidentally create a path from the Guest network to the internal network via Web Proxy.   Bob Alfson (Balfson) has a good document for this, suggest you send him a Private Message to obtain a copy.  

Key items:

1) Guest WiFi must use External DNS (I suggest Quad9 on 9.9.9.9 in place of Google.   More info at quad9 . org ).   Do NOT let Guest WiFi use UTM for DNS, as UTM will resolve addresses using its internal context, which will include some internal addresses.  

2) Do not enable Standard Proxy for any Guest WiFi address, and do not use Pharming Protection, because these also use UTM DNS for name resolution.   Pharming protection is a global setting, so internal users on Transparent Web will lose this protection, but it is only useful AFTER a PC has been infected, so hopefully you will never need it.

3) Filter Actions for Guest WiFi must have explicit blocks for internal DNS domains and internal IP addresses in the WebSites section of the Filter Action.  This means that they should have their own Filter Proflie- Policy - Filter Action sequence.  This is because proxy processing occurs before (and in place of) Firewall Rules.

DouglasFoster said:

If you are using UTM to protect both Guest WiFi and internal users, you need to be careful that you do not accidentally create a path from the Guest network to the internal network via Web Proxy.   Bob Alfson (Balfson) has a good document for this, suggest you send him a Private Message to obtain a copy.  

Key items:

1) Guest WiFi must use External DNS (I suggest Quad9 on 9.9.9.9 in place of Google.   More info at quad9 . org ).   Do NOT let Guest WiFi use UTM for DNS, as UTM will resolve addresses using its internal context, which will include some internal addresses.  

2) Do not enable Standard Proxy for any Guest WiFi address, and do not use Pharming Protection, because these also use UTM DNS for name resolution.   Pharming protection is a global setting, so internal users on Transparent Web will lose this protection, but it is only useful AFTER a PC has been infected, so hopefully you will never need it.

3) Filter Actions for Guest WiFi must have explicit blocks for internal DNS domains and internal IP addresses in the WebSites section of the Filter Action.  This means that they should have their own Filter Proflie- Policy - Filter Action sequence.  This is because proxy processing occurs before (and in place of) Firewall Rules. 

Douglas,

These are good suggestions for many situations in which Guest devices are kept fully isolated and only allowed to communicate through the network to the internet.

These suggestions do not apply to other Guest device situations.  At many locations today, Guest users become internal users.  In these particular situations, it often depends on how you define or label a "Guest Device".  You may hear the term: "Vendor device", "Customer device", "Employee-owned device", or BYOD.

There are a variety of reasons when you want Guest devices to have access to each other or to part of your internal network: local printing, internal server access, remote administration, internal location tracking and product finding, "home automation", and more.

Hi David and welcome to the UTM Community!

Please PM me your email for a copy of "Configure HTTP Proxy for a Network of Guests" and then come back here to make suggestions for improvements.

Cheers - Bob