Captive Portal and https protocol

[MasterZonda]

Hi. When a user connects to the Evil Twin network and tries to access the internet, they are redirected to the fake captive portal even if they are currently on encrypted https sites? I have doubts! The guide says that in this case clients should connect to an http site to view the fake login. But how, since there are no more http websites?

[cjb900]

Depending on the devices most will either automatically popup the captive portal or prompt for a login which will then take them to the captive portal. Its only on some obscurer and or none common devices where the victim may have to navigate to a none https:// website to get the captive portal.

[OscarAkaElvis]

yeah, just typing in the bar "whatever.com" usually creates a first request to http://whatever.com which is valid to trigger captive portal, independently that the website once receive the request is going to redirect you to its https version. If the website has HSTS (Http Strict Transport Security) header, then you can do this only once, and the rest of the times the user tries to access will do it directly to https due to the caching. If is trying to a famous site like microsoft.com, facebook.com, google.com or any of this kind, the request will be directly also to https because that sites are directly included in the internal list that the browsers have to know if the sites have https always enabled (https://hstspreload.org/), so the request will not trigger the captive portal.

I know you already saw "the guide", but I'll leave anyway a link maybe useful for other users: https://github.com/v1s1t0r1sh3r3/airgeddon/wiki/FAQ%20&%20Troubleshooting#once-connected-to-the-fake-ap-created-by-an-evil-twin-attack-the-captive-portal-is-not-automatically-triggered-or-asked-for-what-am-i-doing-wrong

As the link says, I think it's better to have a "page not shown" error than an "insecure page warning" message shown because of a self-signed SSL/TLS certificate. But of course, you can customize your captive portal to set a certificate if you want.

[MasterZonda]

I believe I understand now. In other words, once the client has connected to the fake AP, for the attack to be successful, they need to manually type the desired URL, for example "google.it", into the address bar. This will bring up the fake login page. However, if the client uses bookmarks, history-based link suggestions, or other similar methods, the attack may not work. Therefore, it is essential to hope that the client uses the address bar and manually types in the URLs. Have I understood correctly? If the client does not take this crucial action, the attack may not be successful.

[cjb900]

Not exactly. As previously stated most devices will automatically popup the captive portal or when connecting to the fake AP give some type of indication that a login is required before they are fully connected. Its only in rare circumstances where some obscure/uncommon devices or ones with non-standard configuration where the victim may have to navigate to a non https:// website to get the captive portal popup. So again in most cases the victim will not need to go to a non https:// site to get the captive portal.

[MasterZonda]

I've conducted various tests across different browsers, but the outcome remains consistent. When using personal bookmarks, links, or browser-stored suggestions, I receive either a "no connection" or "page not found" error. This might be due to the HTTPS protocol. Additionally, the portal doesn't automatically connect upon opening the browser. If I manually enter an address, such as "google.it," access is granted.

I apologize if I'm repeating myself, but are there any other tools similar to yours that exhibit the same behavior I've encountered? How can we make it efficient for accessing the portal from both HTTP and HTTPS sites? Unfortunately, if a URL is HTTPS, it doesn't switch to HTTP. Are there any system optimizations or parameter modifications to address this issue? I reside in Italy; perhaps specific parameters are required for my country?

[OscarAkaElvis]

I don't think so. The "solution" seems to create a self-signed certificate and modify the portal and lighttpd config to add it. But in my opinion is worse. No user will enter the password with such warning.

[MasterZonda]

Indeed, if an SSL CA could be incorporated, I believe that browsers, particularly modern ones like Chrome, would display security warnings due to the untrusted certificate, further exacerbating the attack.

Oscar, I have a question to confirm this. If you access a random link from your browser's history or bookmarks, does it consistently direct you to the fake login page?

[OscarAkaElvis]

It depends on the link. If it is Https or not, or if the page is cashed as https due to the HSTS header, or if is a page which is always called using https because of the hstsprelaod list of the browsers.

It is just a DNS black hole where any domain requested is redirected to the captive portal website.

I guess that you could buy a real domain and then a real certificate, something using similar name to the real captive portal connectivity check Google URL for example, and do the needed changes on lighttpd config to redirect all requested there serving that certificate. That way even the Https requests could be redirected to the captive portal serving the legit certificate.

But it is something that we are not going to do because it costs money and it requires maintenance. In addition, this is an open source tool and anybody could use that certificates anywhere. With the proper DNS redirection can be used elsewhere.

Please, if you want to discuss further, join to our discord server. You can find the invitation link in contact section at wiki.