0

So I'm trying to build a malicious captive portal but I'm stuck on the part where you need to know stuff.

Anytime a HTTP request comes in, everything works fine. However, when an HTTPS connection comes in, it refuses to accept my certificate. My phone wont even let me accept it.

So far what I have is the following.

  1. Iptables rule that forwards all incoming traffic to my local webserver on ports 80 and 443

    iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.11.29:80
    iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 192.168.11.29:443
    
  2. SSL Configured for apache with a self signed cert (this was tested and works)

  3. ARP Spoofing my target (Which is my cell phone at the moment)

    arpspoof -I wlan0 -t 192.168.11.1 -r 192.168.11.15
    arpspoof -I wlan0 -t 192.168.11.15 -r 192.168.11.1
    

What the expected result is:

  1. MITM the network via arp spoofing
  2. Regardless what the connection type is, return a captive portal

  3. Allow traffic to flow freely after the person "logs in"

enter image description here

DISCLAIMERS:

  • This isn't for a class
  • Yes I own all the machines
  • I'm not intending on breaking any laws
4

However, when an HTTPS connection comes in, it refuses to accept my certificate.

That's expected. You are trying to man in the middle a TLS connection with a certificate which is either not issued by a CA trusted by the client or where the subject of the certificate does not match the hostname of the target URL. That's exactly the kind of attacks certificate based authentication in TLS is designed to prevent.

My phone wont even let me accept it.

That's likely because you are trying to visit a site with HSTS enabled (i.e. google, Facebook...)

What the expected result is: ... Regardless what the connection type is, return a captive portal

TLS is explicitly designed to prevent any kind of untrusted man in the middle, which means that captive portals trying to use an untrusted certificate (they usually don't have something else) will not work. You either make the clients explicitly trust the captive portal by importing the intercepting CA into the trust store. Or you must rely on the captive portal detection built into several browsers and OS. This detection basically works by accessing specific URL via plain HTTP and check if the results matches the expectations - if not a captive portal is assumed.

See How Legitimate Wifi Hotspots redirect https requests and similar questions on this site for more details.

  • Yes I understand this. However, when I go to starbucks, connect and attempt to establish a TLS connection, I'm returned a captive portal. So there must be some way around it. – Anthony Russell Jun 22 '18 at 1:44
  • 1
    @AnthonyRussell A captive portal doesn't perform MITM for the entire connection. As soon as the user "logs in", traffic is passed untouched. And if a user tries to visit an HTTPS site, the captive portal will fail (this is why neverssl.com is a thing). – forest Jun 22 '18 at 1:44
  • Also I'm not really asking why it's not working. I understand that. I'm trying to resolve it. So if there's a better way I want to learn. – Anthony Russell Jun 22 '18 at 1:46
  • @SteffenUllrich so is the answer to this then "Port 80 will work. Anytime someone requests a TLS connection it will fail and hopefully their browser is smart enough to recognize the captive portal"? – Anthony Russell Jun 22 '18 at 1:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.