Captive portal and HTTPS requests

I have the same issue.

We can't ask guest to install XG cert.

Any suggestion on HTTPS redirect to captive portal?

Hi All,

The certificate error is caused as HTTPS scanning is enabled in the FW rule to forward the hotspot client traffic to internet. Disable the HTTPS scan from the FW rule if certificates cannot be imported.

There is a HTTPS redirect option available in the diagonostics> authentication> authentication service> captive portal > redirect HTTPS. Enable this option to redirect HTTPS connections securely to captive portal.

Thanks

Hello Luk

I was able to recreate this and getting the same behaviour. I was not able to get around this without trusting the appliance certificate. 

The only other workaround I could figure out at the moment was using hotspot, I read earlier in the post that this is a hotspot, so if hotspot and password of the day, or vouchers are enabled, the hotspot captive portal is shown instantly (HTTP and HTTPS). 

Hope it helps.

Varun,

Thanks for your response. Can you track it internally and give us a response ? I am not using hotspot (only have 3 customers do it).

This should work out of the box.

Thanks

HI lferrara, 

Its seems to be an  issue  when redirected to Captive portal page as the certificate is would not be trusted by the system at the start . So This occurrence are known to us ,  Could you all check if the issue is with Mozilla or also in Chrome and Internet explorer. If you have a service request opened in the past for the same issue kindly private message me with the link to this thread as a reference . 

Thanks and Regards

Aditya Patel 

Aditya,

I Tried to access https://facebook.com and what I have seen from the test:

• Firefox 49.0.2 on MAC: HSTS error and you cannot continue
• Safari: works
• Firefox 48.0.2 on Windows: works
• Internet Explorer 11: works
• Google Chrome 54.0.2840.71 on Windows: HSTS error and you cannot continue

Disabling HSTS did not help.

A feature request for this does not exist. On old Astaro.org bug like this were tracked as Mantis and then on community we knew the status (under investigation, fixed into version....).

We can use feature request, but for things that are not working, we need a feedback from you Guys in order to know the status.

Same thing for the Captive Portal (v16) where the network authentication page now is a link. It was working with v15.

If you want that we use feature request, please make sure to change the status on ideas.sophos.com, if you are evaluating them, if the feature will come into next release, build, etc..It is odd that only 5 feature request are under investigation at the moment!

Please provide a way to get people on community informed. Information are spread aroud and this is not a good feedback for community users.This is an example of how tracking bugs was easy and professional:

https://community.sophos.com/products/unified-threat-management/astaroorg/f/utm-9-2-beta/65664/9-200-bug-changes-to-ips-options/250355#250355

Please make sure to use the same Philosophy.

We are more than happy to be here and help you but we need feedback from you. There are many unresolved threads under v16 beta issues/bugs and we do know if they are fixed, will be fixed or...

Sorry if I have added this comment but I am here on the community everyday and I see that finding information or tracking bugs is not easy at all.

Hope that you and Bianson could improve the information and give us more feedback on know issues and their status and not only workaround.

Thanks

Hi Aditya,

I Tried to access https://www.facebook.com on V16, and all of following browsers can't work.

1. Chrome 54.8.2.840.71m
   
   
2. IE 11.321.14393.0
   
   
3. Edge
   
   
   
4. IE 8.0.6001.18702
   
   
   
5. Firefox 49.0
   

Aditya Patel said:

Its seems to be an  issue  when redirected to Captive portal page as the certificate is would not be trusted by the system at the start . So This occurrence are known to us

More and more websites are switching to HTTPS - and I support that, it's a good thing. But the captive portal does not keep up with that trend. It still uses an old fashioned way for redirection. The solution could be a redirection to the captive portal via HTTP (not HTTPS). How hard could it be to set the redirection URL to http://<applianceIPaddress>/<whatever> ?

The next step that I'm taking is to open up a feature request. I'll post the link in this thread later.

I found some interesting and disturbing feature requests.

First the disturbing one: http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/16639819-automatically-displayed-captive-portal

The author complains about the change of connecting to a wireless network and he is right! The method in SFOS 15 was very easy to use. The change really makes no sense for an user friendly perspective. And I won't update to SFOS 16 as long as that hasn't be undone! That feature request will definitely get my support. (This change in SFOS16 is a real roadblock for non-technophile users.)

And now the interesting one: http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/11580213-captive-portal-fqdn-support

Here is the suggesting to use a FQDN for the captive portal. That could work because we could get an official certificate for a FQDN (instead if an IP address). BUT the FQDN has to be available on the internet to get a certificate. This is the downside of this suggestion. You can't use an internal FQDN like https://portal.my.domain . Nevertheless this suggestion also got my support.

My feature request: http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/16916704-captive-portal-redirection-via-http-not-https

You know what to do  ;-)

Community, please take a look at the requests below and support the ideas:

http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/16639819-automatically-displayed-captive-portal

WHY did Sophos change that to a more complicated method??

http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/11580213-captive-portal-fqdn-support

Great idea with a downside: The URL needs to be accessible for the internet. Otherwise you won't get a valid certificate.

http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/16916704-captive-portal-redirection-via-http-not-https

This is my request to change the redirect to a HTTP web site, even is the requested site was a HTTPS website.

thx

Guys, I don't do much firewalling these days but get to stay in plenty of hotels every week. I have a bad habit of using google.com for checking my internet connectivity. I can tell you from experience that whenever I use google.com which redirects to https://www.google.com, I never get any kind of authentication offering from the login system. Iphones usually work fine and you get an immediate login page as soon as you connect to a wifi network that needs authentication (hotspot functionality), however for all PCs etc, I always have to use non ssl website to get to the authentication page.

I don't think Aditya Patel's comment about the issue being known to them means that there is an easy fix. I don't know why he wants to open a feature request on this[8-|]You cannot redirect ssl traffic to a third party without throwing a certificate error. How can you be sure that the website https://mybank.money  is really going to your bank if anyone can hijack your ssl traffic in the middle without any error in your browser? The only way for this to work is to install the certs that are trusted by the client but that is not practical in all cases. Using hotspot or similar where the user authenticates before going to any website is the only way.

On a side note, I agree with . Sometimes its easy to tell the users to open a feature request. I think the most needed feature in XG was to change interface names because it becomes really confusing using port1, port2 etc when you have multiple networks connected to one appliance. We still don't have it in v16. XG gets a ding from everyone on the logging system since its inception. We still have to use cli to grep and tail different logs. Better feedback mechanism was promised during the beta https://community.sophos.com/products/xg-firewall/v16beta/f/sfos-v16-beta-issues-bugs/79949/beta-4-a-disappointment-with-the-limited-fixes-only-no-innovation/305034#305034 but never materialized. Kicking the ball down the road is not the answer to the question that really need a yes/no answer.

Regards

Bill

I think that Sophos should work on error displayed by Browser (for example when HSTS is enabled) using a check mechanism where if the page is not diplayed  within 3/4 seconds, a redirect to another page is done.

The workaroung to redirect to HTTP can be useful but for security reason, plain text format should never been used to prevent that username/password are sniffed.

I am sure that in Sophos they will find the good compromise between security and flexibility.

Hope to see this behaviour tracked internally with NC-XXXX here soon.

Sophos please keep us informed.

Thanks

I think that Sophos should work on error displayed by Browser (for example when HSTS is enabled) using a check mechanism where if the page is not diplayed  within 3/4 seconds, a redirect to another page is done.

The workaroung to redirect to HTTP can be useful but for security reason, plain text format should never been used to prevent that username/password are sniffed.

I am sure that in Sophos they will find the good compromise between security and flexibility.

Hope to see this behaviour tracked internally with NC-XXXX here soon.

Sophos please keep us informed.

Thanks

HI , 

Let me clarify some confusion , are you referring to the Certificate issued while access a Website Via Https and if you proceed it is either blocked or Captive portal .  You could check the link https://www.dropbox.com/s/kfogm6y1fsyb7yv/HTTP%20vs%20HTTPS%20log%20in.mov?dl=0

Thanks and Regards

Aditya Patel| Network and Security Engineer.