There is a system that uses iptables to mark and redirect all connections to port 80 of the web server, the web server, in turn, receives the user's MAC via the command / usr / sbin / arp -an IP and offers to authorize or perform some action.

But there is a problem with HTTPS, i.e. if the user opens http, the gateway will redirect him to his ip on port 80, and if the user opens https://google.com, then the redirection will occur on port 443. This is where the issue with certificates begins, i.e. a google certificate is checked against the gateway domain, and a mismatch error occurs.

How to avoid such a problem? Is it possible to do this via iptables, dns or nginx?

  • here the problem with certificates begins ... How to avoid such a problem? - as far as I know - no way. // your question is too comprehensive. please break it into individual questions. - aleksandr barakin
  • @alexander barakin The question concerns one topic, it will be difficult to break it up into several questions, and if it succeeds, it will be almost the same, at the expense of certificates, there is an idea to work with dns and not mark ports, but deadline = ((( Stanislav Shtepa
  • all the questions on this site "relate to one topic." you have at least two extensive sub-questions. I just recommend breaking up to avoid closing the question as “it’s impossible to give a short answer.” By the way, nothing prevents you from making a link to your other question as a source of a more detailed description of the picture. - aleksandr barakin

1 answer 1

this is where the issue with certificates begins, i.e. a google certificate is checked against the gateway domain, and a mismatch error occurs ... How can I avoid such a problem?

as far as I know - no way. After all, this is the meaning of https connections: so that no one can “pretend” to this site .

Probably the most “honest” way to circumvent this problem is simply to reject such connections ( reject in netfilter terms) - so that the browser immediately tells the user something like “could not connect to the server”.

Here, even in the Wikipedia article about the captive portal, this moment is noted (highlighted by me):

Since the script for working with the captive portal correctly only behaves in the browser when accessing a non-https site

There may be problems with redirection of users connecting from devices that do not recognize the captive portal and open sites that force the use of https (for example, with HSTS enabled). According to Chrome developers, about 5% of SSL / TLS error messages are caused by Captive portals.