Building a malicious captive portal

Question

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"

DISCLAIMERS:

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

Answer 1

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.