Browsing HTTPS sites without authentication in Captive Portal
-
@valdarnini said in Browsing HTTPS sites without authentication in Captive Portal:
I have several users browsing HTTPS without authenticating, a nightmare.
Read this one up untill the end, a it save me explaining what happens when a device connects to a captive portal network.
The minimal version : right after connecting - the connection is user initiated, has he selects the Wifi SSID, or slides in the network cable that is part of a captive portal :
The DHCP sequence start - this happens without any user interaction.
and [the one everybody tends to forget ]
Right after finishing the DHCP sequence, the device will initiate a http (not https !!) request. IOf this test connected correctly, the device knows it is not behind a portal. If it fails (or is redirected elsewhere) then It starts to assume that it's probably behind a captive portal, and fires up an on screen browser with the same request (http URL), this http (TCP, on port 80) request will get redirected to the pfSense captive portal web server : the login page shows up.You've found the rule in In /tmp/rules.debug : there is a rule that redirects ALL TCP port 80 traffic to port 8002 == the internal web captive portal server.
I'm not aware that there are still devices out there (were 2024 after all) that do not support this way of 'captive portal detection'.
@valdarnini said in Browsing HTTPS sites without authentication in Captive Portal:
I had to release DNS query port 53 udp
Release from what ?
Generally : every device on the planet need a working DNS.
Devices on a captive portal : the DNS should "even work better" (which isn't a thing actually - "just don't break it"
). I give yo a hint : DNS traffic is mostly UDP and can also be TCP 
-
@Gertjan said in Browsing HTTPS sites without authentication in Captive Portal:
http request (TCP, on port 80) will be redirected to the pfSense captive portal web server: the login page is displayed.
Yes, all clients are redirected to the captive portal login screen on port 80, but users ignore it, open another browser tab and browse HTTPS sites
What surprises me is that in the latest versions of PFSENSE it was not possible to ignore the captive portal login screen and browse in HTTPS, the user could try HTTP 80 OR HTTPS 443 and everything was redirected to the captive portal login screen and while If you didn't log in, you wouldn't be able to go online.
You've found the rule in In /tmp/rules.debug : there is a rule that redirects ALL TCP port 80 traffic to port 8002 == the internal web captive portal server.
Yes, I found it and it has the rule as reported
thanks
-
@valdarnini said in Browsing HTTPS sites without authentication in Captive Portal:
Yes, all clients are redirected to the captive portal login screen on port 80, but users ignore it,
So they see the login page and ignore it ?
Ok, wow, - now I'm curious.
In what kind of structure are you using the portal ? Elementary school ?
(What country ?)
[ sorry ]@valdarnini said in Browsing HTTPS sites without authentication in Captive Portal:
What surprises me is that in the latest versions of PFSENSE it was not possible to ignore the captive portal login screen and browse in HTTPS, the user could try HTTP 80 OR HTTPS 443 and everything was redirected to the captive portal login screen and while If you didn't log in, you wouldn't be able to go online.
Be assured, that's still the case. Except for DNS (you have to allow port 53, TCP & UDP, the access to the PfSense portal IP where the pfSense Resolver will serve them) everything should be blocked.
If not, you have a major firewall (rules) issue.
On my captive portal, nothing is possible - like all ports, IP's, protocols, they can't pass. This the the firewall's 'pf' default behavior.
For a device to 'pass', its need to made part of the portal's "allow rule", and the portal login page will put the device's MAC and IPv4 into that rule.This always worked for me, since pfSense, even before "version 1". I never had to change something in my set up during all the upgrades.
Just to be sure, you did not check this one :
right ?
@valdarnini said in Browsing HTTPS sites without authentication in Captive Portal:
the user could try HTTP 80 OR HTTPS 443 and everything was redirected to the captive portal login screen and while If you didn't log in, you wouldn't be able to go online.
Normally, users using device that they connected to your wifi (or cabled) captive portal network don't need to do anything, as they don't have the time to try 'whatever'. On my portal network, in a split second, my "login with user ID or go play elsewhere" page will open full screen. If the user can read, they know what to do. If they can't, or, as you said, ignore it, the issue isn't yours or pfSense related.
-
@Gertjan said in Browsing HTTPS sites without authentication in Captive Portal:
So they see the login page and ignore it ?
Exactly, they fall to the login screen and ignore it, to show you I installed another PFsense with a captive portal and the error persists, in this case of the example I used the same LAN, but on my main network I use OPT1, here is a link to a video I made to show what is happening.
https://www.reddit.com/r/PFSENSE/comments/1alcwzc/browsing_https_sites_without_authentication_in/?utm_source=share&utm_medium=web2x&context=3
@Gertjan said in Browsing HTTPS sites without authentication in Captive Portal:
In what kind of structure are you using the portal ? Elementary school ?
company, but one discovered it and passed it on to the others
@Gertjan said in Browsing HTTPS sites without authentication in Captive Portal:
(What country ?)
Brazil
@Gertjan said in Browsing HTTPS sites without authentication in Captive Portal:
right ?
OK, this option is uncheckedThank you for your dedication
-
@valdarnini said in Browsing HTTPS sites without authentication in Captive Portal:
https://www.reddit.com/r/PFSENSE/comments/1alcwzc/browsing_https_sites_without_authentication_in/?utm_source=share&utm_medium=web2x&context=3
With these LAN firewall rules :
devices on LAN can reach 'pFsense' (the IP of the LAN interface) to port 53 - TCP or UDP. So DNS should work.
The next rule will block all IPv4 traffic. All IPv6 traffic (if any) is also blocked by the 'hidden' final rule : block everything.
The video was clear enough : there are no other interfaces on the device (PC) used. No VPN used.
I've activated the portal on my own LAN, using 'http' (no https) login. All devices were locked out right away. I places used your firewall rules my LAN : only DNS to pfSense, and everything else blocked.
After login, I couldn't access any websites, I've tried several PC's. The traffic counter of the red, third bock' rules was not zero (0/0) as traffic was hitting that rules as it was blocked.So, "something else" is passing your traffic.
Can you show /tmp/rules.debug ?And, just to be sure : You're using
The behavior continues when you disable that option ?
-
@Gertjan said in Browsing HTTPS sites without authentication in Captive Portal:
So, "something else" is passing your traffic.
follows rules.debug
I tried to post in plain text, but it was detected as spam, follow .txt via wetransfer
https://we.tl/t-U8qOxlHgwK
@Gertjan said in Browsing HTTPS sites without authentication in Captive Portal:
The behavior continues when you disable that option ?
yes, I removed this bandwidth control and the same thing happens.
NOTE: HTTPS sites that are on the block list are blocked.
Thanks
-
@valdarnini said in Browsing HTTPS sites without authentication in Captive Portal:
https://we.tl/t-U8qOxlHgwK
You are using squid ?
With a captive portal ? ? -
@Gertjan said in Browsing HTTPS sites without authentication in Captive Portal:
You are using squid ?
With a captive portal ? ?Yes, I'm using it transparently, I've been using it since version 2.3.2
I have to block some sites and get browsing logs
Is there anything I can do to work with CP and Squid?
Or something that replaces squid along with CP?Thanks
-
Not that Netgate doesn't want squid anymore.
squid itself has a hard time supporting itself, development, amongst other, has become an issue.What I'll add now is only my opinion :
We are all for a secure internet usage.
This can only be possible if the communication channel used is secured.
So, TLS is has become unbreakable by the NSA, and all 3 letter agencies.
read and decode this one.
This implies that all the others, like you and me, can't create an easy exception anymore.
That is : one still exists : for every device in your network, assign a proxy = pfSense. The proxy will do the request in behalf of the device / the user.
But ... more and more, proxy request are not acceptable (anymore) for the server side. More and more servers want to 'talk' to the device of the user, not some sort of MITM (proxy).
So, maintaining squid means maintaining a list with 'not to squid this site'. And eventually every site on planet earth will be on the list. Squid = game over, security wins.What finally happens is : if you want to 'share' your internet connection, do it with people you trust. And stop thinking about it, and make yourself ready to assume consequences when they fail on you.
If you have any doubts, just don't.Again : take note : I hope to be wrong, of course.
-
@Gertjan
ehhh. I totally understand where you are coming from but i would also state that proxies - at least custom proxies deployed by other firewall vendors - do much more than just break a TLS session and see if you are going to a porn site.
There is A/V scanning, threat prevention, and content control. So there are more things happening under the hood.
pfSense does not have the ability to pass broken TLS sessions from Squid to Suricata for further scanning. If it did, then i would be all up in arms regarding the depreciation of Squid on the platform. Fundamentally, Squid as designed doesn't really increase security on pfSense. Doesnt really do much of anything other than cause headaches and there are already better tools like pfBlocker to do conent control.
What squid needed was better integration with other tools on the firewall . -
Don't worry, I get it : most countries on this side of the globe do hold the subscriber responsible for abuse and mise use.
In my case : if someone in a hotel room tries to launch the french nukes, we will see the black helicopters all around the building, and we will see the guys that shoot first and ask question later.
To make a long story short, the 'owner' will go to prison, not the client.
So yeah, it might be useful to know what a client does with 'our' connection.
[ I have a spare owner, if the first one goes down (85 years so ...) the I have a spare one ]@michmoor said in Browsing HTTPS sites without authentication in Captive Portal:
There is A/V scanning, threat prevention, and content control.
I've no 'I have the kids Internet access and now they can see awful things' problem anymore. Mine were adult the day smartphones saw the light.
Hotel clients : they can do with the connection what they want : its fine with me that thet download that latest virus, or scan my antire portal network (all clients live in their own sandbox all walled garden ...)If I had a company with a bunch of employees and their (mine !) devices that know nothing about everything, I would post here with another vision
I would start with what the squid authors say upfront : it belongs on a dedicated device / proxy server, as that service will be way to important at that moment.
So, most probably : a router/firewall is a router firewall.
A proxy server is a proxy server.
Etc. -
@Gertjan
Agree with you :)
If there is a great need to inspect traffic, best to do that on a dedicated device OR get services such as Cisco Umbrella that will handle all the DNS requests and do web filtering categorization.
Make the firewall a firewall.
Make the router a router.
Make the proxy a proxy.@Gertjan said in Browsing HTTPS sites without authentication in Captive Portal:
So yeah, it might be useful to know what a client does with 'our' connection.
Captive portal? Like you, i dont care what a client does on the internet. They route out a privacy VPN anyway and do not harm the IP reputation of my WAN IP.
Corporate users? If it were my network i would install endpoint tools to monitor everything. No need for Squid.
For home? good luck :) -
Thanks for the answers, it's clear.
However, while you still have squid in the PFSense 2.7.2 package, I would like to continue using squid, in the meantime I gain time to think about something or leave it without squid and follow the recommendations.
As there is still squid in the package, is there no rule I can apply to block 443 HTTPS access before authentication on the captive portal?
thank you all
