Captive Portal don't block HTTPS Site
-
Hello everyone,
I have a small problem with the captive portal. I did not activate the https login due to certificate problems, and since then it does not block HTTPS sites.
In HTTP it redirects correctly, but HTTPS you can access the site without being connected to the portal.
I did some tests and I have the impression that it comes from the option: SSL Man in the Middle Filtering from squid 3 in transparent mode.Also, is it possible to redirect HTTPS sites to my HTTP captive portal (I think there are already posts talking about this but I haven't found a solution)
Thank you very much
-
@exotic69 said in Captive Portal don't block HTTPS Site:
possible to redirect HTTPS sites to my HTTP
Not on the 'Internet' as we know it, as that would introduce a massive security issue.
Redirecting from http to https, that's ok, and what is happening all the time. For example, when you visit http://forum.netgate.com (implies a connection to the host at forum.netgate.com on port 80, the web server will reply with a resulting code "301" and a new URL like https://www.netgate.com (implies port 443), and the browser will continue on from there.@exotic69 said in Captive Portal don't block HTTPS Site:
I have a small problem with the captive portal
Never used squid before, and using it on a captive portal seems a lot of administrative pain to me.
So : easy solution : stop squid on the portal, and case solved
What I do think that happened : the user (IP) was authenticate by squid to use the (portal) network, and from now on the squid pass rule takes presence over the portal (default block) rules.
But I can be wrong of course.@exotic69 said in Captive Portal don't block HTTPS Site:
I did not activate the https login due to certificate problem
I'm using it all the time, as forcing unknown people, the portal users, to use a "http" web page instead of a https web page is a "bad" think.
Activating "https" does mean that you have to have a certificate that is trusted by every web browser. You can't make your own, because you, as a certificate signer (generating a auto signed certificate), are not listed in every web browser on the planet as a known certificate signer.The good news : pfSense has a package called 'acme' that can obtain and maintain a certificate for your pfSense, your captive portal that will be trusted by everybody.
And it also looks better : instead of presenting the portal user with an URL like "http://192.168.2.1:8002/index.php?zone=cpzoneX&redirurl=....."
he will see
"https://portal.yourdomain-site-brand.com:8002/index.php?zone=cpzoneX&redirurl=....."Obtaining the certificate is free, but you need to give proof that you have control over "yourdomain-site-brand.com". Or : you need to buy (rent !, about 10$/€ a year) yourdomain-site-brand.com (good news, its available).
Don't run of tho the first registrar and get it, do what you do when you buy a car : compare, check what they offer, check what you need first.
When you have the domain name, use the acme package to get you a "portal.yourdomain-site-brand.com" and use that URL and certificate as your captive portal access.
The certificate will auto renew from now on, acme will take care of that.Btw : doing MITM on a captive network == doing MITM on traffic from people that I don't know, is probably enough to have me locked up for a while (I'm not working for the government, but a company in a somewhat 'free' country (France)).
That said, I'm also 'responsible' for the traffic that I output and input on 'our' Internet connection.
What I do, if needed : I route out the captive portal traffic over a VPN to some remote "other side of the planet" ISP-VPN. And yes, at that moment, my captive portal users will have huge problems login into their gmail, their Netflix access won't probably not work anymore, they couldn't visit their bank's web site anymore without triggering loads of warnings, but at least, if some one was really trying to launch some local cruise missiles from our hotel rooms, it wouldn't be me winding up in prison. -
@Gertjan
Thank you for your answer. I need a proxy and i don't know how to place the captive portal before the proxy.
For redirection, my pfsense will just need to send back to the portal when it detects an access request to an HTTPS site
I cannot buy a domain and then put a certificate because the captive portal is in my local network (LAN) which is in home.lan or or I'm not aware that it's possible.
Otherwise, everything seems to work with the portal in HTTPS, except Chrome which does not detect the portal and IOS which poses a problem. -
@exotic69 said in Captive Portal don't block HTTPS Site:
I cannot buy a domain and then put a certificate because the captive portal is in my local network (LAN) which is in home.lan or or I'm not aware that it's possible.
My pfSense is also hooked up to my ISP, and my LANs are also RFC1918, it is 192.168.1.1/24 for my LAN, 192.168.2.1/24 for my LAN2 called Portal. As I company I wouldn't call my network "home.lan".
I did buy (rent) a domain name like "my-hotel-brand.net" and used it like this :
Now i can visit
without my browser complaining.@exotic69 said in Captive Portal don't block HTTPS Site:
I need a proxy and i don't know how to place the captive portal before the proxy.
Check also here.
@exotic69 said in Captive Portal don't block HTTPS Site:
and IOS which poses a problem
I'm using iOS 17.1.2 myself right now, no issues.
-
@Gertjan
all my problems would therefore come from the certificate...
My WAN is also a private network, pfsense is behind an orange livebox. Is it disturbing? -
@exotic69 said in Captive Portal don't block HTTPS Site:
pfsense is behind an orange livebox. Is it disturbing?
Like my pfSense. A livebox 6 - orange.fr as ISP. Works "well"' if you don't have big exceptions about IPv6 (only one prefix).
Btw : Be careful : doing MITM on people that are not your family is dangerous. People have been brought to La Bastille to have their heads exposed for less then that.
A certificate can't be a problem, as they are free, 'easy' to set up. Using the pfSense acme package for years now.
-
@Gertjan
ça va être plus simple en français (si j'ai le droit). C'est pour mettre sur un réseau wifi public, et donc si je comprend bien, je peux attribuer un vrai nom de domaine sur un pfsense avec certificat fonctionnel du côté WAN et LAN derrière un livebox sans avoir de problème avec les navigateurs ? -
@exotic69 said in Captive Portal don't block HTTPS Site:
wifi public
Comme moi : un accès wifi pour le client de notre hotel.
Et comme j'ai dit plus haut : pas de MITM pour moi. Je ne cherche pas à savoir ce qu’ils font les gens avec leur connexion. C'est privé. Et c'est vrai, en cas d'abus, c'est le 'patron' qui va en prison, car c'est lui, la responsable de la connection, c'est lui qui doit répondre en cas de requête de la part de "hadobi", etc. mais, depuis 2001 ( ! ) je partage notre connexion Internet avec nos clients de l'hôtel, jamais eu des problèmes.
Probablement lié au fait que j'ai partagé 18 Mega octets/seconde (ADSL) (en 1 Mo/sec en émission) donc rien va très vite. Ca a changé depuis janvier dernier : 1 Go symétrique fibre : youpi.Le certificat : nous sommes une société, j'ai donc quelques noms de domaines (chez OVH bien sur). Un nom de domaine est réservé pour l'usage interne - notre LAN de pfSense.
Je loue donc "my-hotel-brand.net" : un dot net, c'est env 14 € par an.
Car j'ai un nom de domaine 'à moi' je peux donc utiliser le pfSEnse package pour qu'il me donne un certificat, je demande carrément un wildcard "*.my-hotel-brand.net" donc le certificat obtenu fonctionne pour
pfsense.my-hotel-brand.net mais aussi pour
portal.my-hotel-brand.net (le portail captive de pfSense)
et aussi :
imprimante.my-hotel-brand.net, nas.my-hotel-brand.net et clim.my-hotel-brand.net etc etc, toutes mes appareils dans mon LAN qui ont un GUI et je peux maintenant les accéder par un https://....
Après tout : l'accès "http" est à bannir partout où c'est possible, le http fait partie du passé.
Typiquement, seule les requetés DNS passent encore en clair.
Sache que les clients qui ont un truc à cacher
activent leur VPN dès qu’ils ont ouvert l’accès avec le portal captive. Tout le monde le sait d’ailleurs ; si t’es pas chez toi, après la connexion : active ton VPN. Et voila une autre raison que ‘MITM’ ne fonctionne pas.Le fait d'avoir un certificat signé par Letsencrypt m'assure que mes clients peuvent se connecter sur notre portail avec un URL comme "portal.my-hotel-brand.net" sans aucun message d’alerte - sans qu'un IP comme "http://192.168.2.1" s'affiche.
Si t'es pas loin de Lot et garonne (47500 Fumel) : viens voir
@exotic69 said in Captive Portal don't block HTTPS Site:
ça va être plus simple en français (si j'ai le droit)
Pas une question de droit, mais de 'logique'. Un forum anglais 'pollué' de russe, chinois et égyptien n'est guère utile pour personne. Même Google va plus comprendre.
C'est mieux de continuer ici : Home > pfSense > International Support > Français.
-
E exotic69 referenced this topic on
