Block Page certificate error for Hotel guest's - no option to add Fortigate CA at endpoint.

[EyponeDK]

Hi All,

I have a hotel as a customer, and we recently replaced their Firewall with a Fortigate.

The hotel is blocking certain web categories, but when the hotel guest is intercepted with the block page they get an certification error, but cannot continue to see why they were blocked!

I think it was possible in previous version of Chromium based browser to click advanced an continue to see the block page.

I know how block pages is working when running full SSL inspection OR having the option to install the Fortigate CA to the client 'Trusted Root Certification Authorities' store.
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Certificate-error-when-accessing-blocked-p...

The replaced Firewall was another brand, and was redirecting user to a specific Block Page.

This Block Page I was able to add a hostname and get a certificate from a public trusted CA.

Can something similar possible be done on a Fortigate, or how have you solved it ?

I can’t ask the staff at the hotel lobby to install the fortigate CA guest endpoint.

I hope someone have been in the same situation and solved it.

[smayank]

Hello

Please check for this link.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Certificate-error-when-accessing-blocked-p...

Thanks&Regards
Mayank Sharma

[pminarik]

The short version of the story is that redirection to captive portal is functionally the exact same action as redirection to a block page with certificate/deep-inspection. If the requested page is accessed over HTTPS, this will trigger certificate warnings if the inspection CA isn't imported, and this is unavoidable. (in case of captive portal the MITM/DPI CA would be set as auth-ca-cert in config user setting)

There's a small change that I've seen help in this situation, though I would not expect it to be bulletproof. You can try it if you're interested.

Disable redirection of HTTPS requests:  

config user setting

set auth-type http # default is:  set auth-type http https ftp telnet

end

=> as a result, any HTTPS requests that would otherwise be redirected to the captive portal (and cause certificate warning), will now be simply dropped. (note: this is a VDOM-wide setting, so be careful if you also have corporate devices in the same VDOM, trusting your deep-inspection CA, and expect to use captive portals for them as well)

As far as I am aware, there are no clients that use exclusively HTTPS for internet access probes, so this should still work, and as soon as the guest device sends a probe with a plain HTTP request, it should detect the captive portal.

Strictly speaking this relies on clients sending HTTP probes, so if things don't work as expected, you know what to look for in your pcaps. (check if the clients send plaintext HTTP probes as well :) )

With this baseline setup (disabled HTTPS portal redirect), you can either use the portal on plain HTTP, or enable redirect to the HTTPS version of it, which will also require to configure a valid certificate for the portal URL (FQDN or IP).

[EyponeDK]

Okay. 

Just to be clear, the captive portal do not have anything to do with block pages only if the need to hotel guest to sign-in or accept terms and conditions before connection. 

For the block page there is no way to get FG to redirect to a specific page instead of MiTM ?

If NO i do not see FG offer a public solution for block pages as you can't use a public CA as an CA for MiTM. 

[pminarik]

Ah, correct. Captive portal is unrelated to basic block pages. I misread the thread, my apologies.

However, the general statements in my previous post still stand. Even for block pages.

The behaviour depends based on whether the original request made by the client was HTTP or HTTPS.

HTTP: Trivial to redirect, no security, no certificate errors (because no certificates are used).  

HTTPS: A successful MITM (doesn't matter if it is a malicious attack, redirect to a block  page, or a redirect to a captive portal) must present a certificate that the client trusts - issued for the webpage being originally requested (FQDN typically), and issued by a CA the client trusts.

Nobody, no vendor, has the ability to do this to arbitrary guest clients (=does not trust your MITM CA). If some security device were able to do this, this would mean that TLS is completely broken, and consequently the majority of internet security would be broken as well.

If you don't believe me, try going to some café nearby which has a wifi and a captive portal, and see what happens if you try to open something a website while ignoring the portal login/disclaimer. The typical results are one of:

a, HTTPS simply dropped  

b, HTTPS certificate warning (an attempt to MITM and redirect, naturally failing, as explained above)  

c, HTTPS "just works" (wifi doesn't enforce passing through the portal first)

With regards to your note about this possibliy working in earlier version of Chrome/Chromium: This may be related to Chromium somewhat recently introducing a change to try opening all websites over HTTPS first.

Before:

open "www.example.com" => tries HTTP first, unless explicitly including "https://" or unless the website has cached HSTS directive

After (Chromium 90-ish I think? Not sure):

open "www.example.com" => tries HTTPS first, falling back to plain HTTP if there's no response for HTTPS.