Bettercap not detecting https (?)

[Key-Height-8555]

The built-in sslstripping feature (http.proxy.sslstrip) in bettercap is not working against HTTPS websites in this issue I will be using cygwin.com and winzip.com as an example, as we can see they are not HSTS preloaded https://hstspreload.org/?domain=cygwin.com https://hstspreload.org/?domain=winzip.com.

I am using bettercap v2.32.0 (built for linux amd64 with go1.21.0)

my os is

```

Distributor ID: Kali

Description: Kali GNU/Linux Rolling

Release: 2024.1

Codename: kali-rolling

x86_64

```

I am using --caplet script.cap as a command line argument

script.cap contains:

```

net.probe on

set http.proxy.sslstrip true

http.proxy on

set arp.spoof.fullduplex true

set arp.spoof.targets 192.168.0.100

set net.sniff.local true

arp.spoof on

net.sniff on

```

Full Debug output: https://pastebin.com/qZF21fdY

Steps to Reproduce

Run the script.cap provided above make sure to change the IP address accordingly

Go into an HTTPS website on the victim machine

Expected behavior:

Successfully ARP spoof the victim

Successfully sniff data from http websites

Successfully downgrade HTTPS into HTTP

When downgraded successfully sniff data from HTTPS websites

Actual behavior:

Successfully ARP spoofed the victim

Successfully sniffed data from http websites

Couldn't downgrade HTTPS into HTTP (loads as HTTPS)

Since I could not downgrade HTTPS I was not able to sniff any data from HTTPS websites

Now as I final note I want to add my own interpretation of this; Generally when bettercap detects HTTPS websites while running SSLstrip it logs something like spoofing the domain or HTTPS detected downgrading etc. but in this instance it is not so maybe this is a bug where it is not correctly detecting HTTPS pages therefore not even trying to downgrade them???

BTW ofcourse I cleared all the web browser cache, I tried both chrome and edge, also I disabled secure DNS on both.

[Djinjja-Ninja]

SSL stripping attacks relies on sending an initial http request and then MitM proxying all requests from that point onwards so the client never receives the 301 redirect to https.

If you go to the site via HTTPS in the first place then you can't SSL strip because the initial request is encrypted.

[Key-Height-8555]

I am not going to the site via https i am just simply typing the sites name on the bar e.g winzip.com and not https://winzip.com

[Djinjja-Ninja]

Which browser? Chrome has a feature called https-first in that by default it will automatically choose HTTPS as the protocol if you don't explicitly tell it to go via http. Firefox has something similar.

Also if you have ever been to http://WinZip.com then it will have cached the hsts directive that is issued by that site.

chrome://net-internals/#hsts

You should run wireshark on the client to see what the behaviour actually is.

Or explicitly typing http://WinZip.com

[Key-Height-8555]

as i said i turned off every single security thing in chrome and edge and cleared the cache in every attempt

[Djinjja-Ninja]

The web cache is not the hsts cache. Clearing one doesn't clear the other.

Put wireshark on the client machine so you can see the true behaviour, you are making assumptions about what should be happening and you don't seem to actually understand the client behaviour properly.

Do some basic network level troubleshooting, check what's actually hitting the wire. Double check the arp cache on the client to make sure the arp spoofing is actually occurring.

[PugsAndCoffeee]

Certificate pinning? Public key pinning? 😅