I've been following this guide: https://www.cybrary.it/0p3n/using-sslstrip-in-kali-linux/ and others too, ex: official Sslstrip one: https://moxie.org/software/sslstrip/ without any success.

I'm using:

5.2.0-kali2-amd64 #1 SMP Debian 5.2.9-2kali1 (2019-08-22) x86_64 GNU/Linux
sslstrip 0.9 by Moxie Marlinspike

and arpspoof.

I am running first:

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A PREROUTING -p tcp  –destination-port 80 -j REDIRECT –to-port 8080

Then arp spoofing:

arpspoof -i <interface> -t <targetIP> -r <gatewayIP>

Then sslstrip:

sslstrip -w testfile.txt -l 8080 

Then I'm going to my target machine, iPhone running Safari browser. I'm deleting all cache and temp. I'm browsing to non-HSTS preloaded websites (linkedin.com , zsecurity.org ). I'm not specifying https:// , but simply the domain name (ex: linkedin.com). They still load in https.

I tested this multiple times on another client running Windows and Internet Explorer. Same result, I cannot have the target forced to http.

The testsfile.txt from sslstrip is empty. I was expecting the client would open http web-pages.

What am I doing wrong?

  • I want to add some potentially helpful information. I'm running the procedure above, then I'm opening my Wireshark. My belief is: my target-client should be arp spoofed and re-route its traffic to my Kali. Hence I should see requests for linkedin and zsecurity in my Kali. I cannot find those requests in my Wireshark capture. I can see that some traffic is being redirected from my iPhone's ip to my Kali, but not the requests for those web pages. Could this be the problem? I'll now post some examples in my next comment.
    – lorelou
    Sep 17, 2019 at 9:02
  • Examples packets from Wireshark on my Kali. = Kali doing the arp spoofing. = iPhone is target-client. 92 5.679089437 TCP 78 54205 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=128 TSval=1042927190 TSecr=0 SACK_PERM=1 [...] 95 5.683192043 HTTP 368 GET /MFYwVKADAgEAME0wSzBJMAkGBSsOAwIaBQAEFN%2BqEuMosQlBk%2BKfQoLOR0BClVijBBSxPsNpA%2Fi%2FRwHUmCYaCALvY2QrwwIQDHmpRLCMEZUgkmFf4msdgw%3D%3D HTTP/1.1
    – lorelou
    Sep 17, 2019 at 9:26
  • I believe the above comment shows packets with source ip of iPhone are going through my Kali. There is no DNS traffic for linkedin nor zsecurity though. No HTTP traffic either. No mentions of them at all. If I search for ARP traffic, I can find such messages: [Duplicate IP address detected for (<MAC ADDRESS>) - also in use by <MAC ADDRESS> (frame 9)]. I believe this message to be normal, as I'm arp-spoofing.
    – lorelou
    Sep 17, 2019 at 9:34
  • You should Setup your own local server to test more completely. You are probably running awfoul of the strict-transport-policy header Sep 17, 2019 at 10:17
  • Could you elaborate some more? I'm testing this in my own network, own router, all devices are my own. What did you mean by setup my own local server? Maybe a vm running in the same Kali client?
    – lorelou
    Sep 17, 2019 at 13:40

2 Answers 2


First of all: What sslstrip does is it replaces https-links with non-https-links on hijacked non-https- websites. E.g. when the victim visits a http-only search engine via an insecure public wifi, the attacker can use sslstrip to replace https-links in the search engine- results with http-only links.

I guess that the websites you are targeting (e.g. linkedin) always redirect to https, regardless of what the victim attempted to open. And won't allow http-connections in the first place.

And last but not least, like others already mentioned in the comments, the target websites most likely set a strict-transport-security header in the first response (or even an OPTIONS response, which can be easily overlooked), which will prevent the browser from allowing http-only connections.


I think deleting cache and tmp should not be sufficient to remove the HSTS entries. For the safari browser e.g. there is the file "~/Library/Cookies/HSTS.plist" where HSTS is safed. You would need to remove this file when testing from a desktop.

  • Hi state, Thanks for contributing. I'm not browsing to HSTS web-sites. You can check here: hstspreload.org/?domain=linkedin.com In my iPhone i'm going to Settings > Safari > Clear History and Website Data ("Clearing will remove history, cookies and other browsing data. [...]" ). Then I'm checking the Advanced > Website Data menu, I'm making sure all data's been erased from there. In my Windows desktop I'm going to IE's internet options and deleting all history, temp, cache.
    – lorelou
    Sep 17, 2019 at 8:55
  • 4
    @lorelou HSTS is more than just the preload list. There is also the strict-transport-security header which is set in the response from the server. LinkedIn sets it to one year. It would not show it in the browser preload list. I don't know where the browser stores it but you probably can't clear it. This is likely the answer. Sep 17, 2019 at 10:16
  • Hi @ConorMancone , thanks for pointing this out. I checked the web-dev-tools for linkedin.com and found the header "strict-transport-security: max-age=2592000" in response to the 301 moved permanently. This appears only on linkedin.com though and not on zsecurity.org, there is no such header there. Nonetheless I'm unable to downgrade the latter from https to http.
    – lorelou
    Sep 17, 2019 at 13:38
  • @lorelou Yes, that strict-transport-security header enables HSTS on the site even if it isn't on the pre-load list. As a result if you had previously visited a site that returns that header, sslstrip is impossible. That would explain linked in, but obviously not zsecurity.org. Sep 17, 2019 at 13:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .