6

Usually I try to tell people not to input any data on websites that are not secured with HTTPS.

Given that most people are secured by Wifi access control. How bad is it really?

What are possible attack scenarios?

How easy is it too intercept HTTP data?

For example a simple attack would be to abuse a common Wifi like in a coffee shop. However, if the data you are protecting is only a privacy issue that still requires a targeted attack and might be too contrived.

Edit: I removed the mention of SSLSTRIP. Stripped connections will look like normal HTTP connections to the user. So if the users actually check that they have an HTTPS connection it will not work.

7
  • 1
    Cleartext means attacker in coffee shop injects javascript into any page and runs code in context of any origin. Steals cookies, does bad things using your accounts. HTTPS with HSTS is only thing that helps against attacks like samy.pl/poisontap
    – Z.T.
    Nov 29, 2016 at 0:14
  • Firesheep is no longer working; but the idea is still sound. pcworld.com/article/209333/… Also, consider the common practice of ID/password reuse - getting someone's credentials for one site might mean getting their credentials for ALL sites.
    – gbroiles
    Nov 29, 2016 at 0:33
  • 2
    Not so dangerous if contents of that website are 100% public.
    – defalt
    Nov 29, 2016 at 7:47
  • @user334283 unprotected 100% public websites are great only for malware injection and tracking which pages you browsed.
    – Z.T.
    Nov 29, 2016 at 11:17
  • 2
    @user334283 100% public means there's no secrets, but that doesn't mean you don't want to protect it. HTTP still leaves it open for tampering as Z.T. suggested, malware can be injected into it, the contents of the page can be changed to give misinformation, a fake login prompt could be inserted, lots of malicious tampering can be done. TLS is not just for privacy, it's also for integrity. Nov 29, 2016 at 15:50

4 Answers 4

5

Usually I try to tell people not to input any data on websites that are not secured with HTTPS.

That's good advice.

Given how efficient SSLSTRIP is and that most people are secured by Wifi access control. How bad is it really?

For people who follow the above advice, SSLSTRIP has no effect because they (should) notice that their browser is not using HTTPS.

How easy is it too intercept HTTP data?

With a rogue access point it is very easy. With a rogue cable modem on the same network, it is possible but difficult. DSL is harder as the lines are dedicated.

1

It is trivial to intercept traffic in most networks by redirecting the traffic to the attacker using ARP or DHCP spoofing attacks so consider any public hotspots insecure. Also the attacker can create its own rogue hotspot with the name of a well known ISP and users will happily connect to it. And many routers can be exploited too to change settings which cause all outgoing traffic to be redirected to the attacker. And in addition to such attacks which redirect the traffic to the attacker for easy data extraction browser injects and other malware can be used to intercept traffic directly at the client system.

There is no deep technical knowledge needed by this: there are simple to use tools and tutorials which allow anybody to do such attacks. Just google for tutorial man in the middle attack and see for yourself.

1

MiTM, script injection, or rouge AP aside; http can also be sniffed via monitor mode if over insecure Wi-Fi without being attached to the AP and/or over password protected Wi-Fi if the attackers' device is on the same network... attacks are already well documented on Aircrack-ng's home page so I'll instead advise some mitigation options.

Option 1; notify the site admin that SSL certs can be had for free from LetsEncrypt and the gains in client trust that can be had by using https instead of http.

Option 2; setup a personal VPN for your access point and provide keys to your clients such that their traffic is encrypted over Wi-Fi regardless of protocol before being sent over an Ethernet connection to your modem. Routers that are open firmware friendly and PC on a chip devices (like beaglebone or raspberry pi) are the cheapest way of setup but you could also setup a VPN on a VPS for around the same cost as the electric bill of a local server setup.

Personally I've opted for option two because it's a pain to try and get some admins to even respond let alone be responsive about encryption when they've already enough on their work schedule.

Edits/Updates

  1. As commented below a GitHub repo Perinoid_WiFi has been initialised that will eventually contain notes and scripts for setting up your own AP with a VPN+DNS server for encryption of network traffic over Wi-Fi. Though wait till the end of this month or an update here before using because there's an extensive amount of setup that will be merged into the above repository.

  2. OpenVPN server & client setup nearing completion, iptables and DNS server setup and few other features remain unincorporated. Contacting Travis-CI team for assistance with easy-rsa dependencies such that builds' steps maybe verified before downloading project.

  3. Server and client config process complete and tested publicly with Travis-CI, one of two iptables scripts also incorporated. DNS and sandboxing still to be merged, however, the above is now functional so feel free to test it out and or submit bugs/issues to GitHub if there are any... in other words happy holidays to y'all and enjoy the cryptic gift ;-)

4
  • So you're saying you tunnel everything to a private server for extra security? Nov 30, 2016 at 23:47
  • When ever possible over wireless I'll encrypt prior to data hitting the wire; ssh and other protocols required a bit of extra setup... I've just stabilized my last project so I'll get to work scripting up my process of vpn set up soon; expect something worth while by the end of the month on GitHub ;-)
    – S0AndS0
    Dec 2, 2016 at 3:55
  • Note that personal VPN doesn't really solve the problem of your connection being MITM-ed, it only moves the problem from your local access point to the VPN server's network. This is OK if your threat model is rogue coffee shop owner while you're roaming away from home, but for those who need security against targeted attack by government, rogue ISP, APT, or large corporate espionage, this isn't going to cut it.
    – Lie Ryan
    Dec 19, 2016 at 10:28
  • Very true Lie Ryan because eventually the data has to be readable to the client and the servers they wish to connect to. Though with the threat models you've described it's still possible to mitigate some risks by chaining VPN connections (local server to remote server on a different ISP) combining that with additional tunneling via Tor or other packet obfuscation services between VPN servers things get more expensive for unauthorised sniffers or drive-by injection. Though like you've stated, if a state level actor wants your bits, they'll just scoff at the increased expense.
    – S0AndS0
    Dec 19, 2016 at 16:37
0

It really depends on what data you are transferring. HTTP is an unsecure protocol. You could easily use a sniffer to inspect the TCP/IP packet information.

1
  • This adds nothing to the existing answers.
    – Chenmunka
    Dec 6, 2016 at 18:54

You must log in to answer this question.

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