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.

Corporal Touchy
  • 837
  • 1
  • 6
  • 10
  • 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 https://samy.pl/poisontap/ – Z.T. Nov 29 '16 at 00:14
  • Firesheep is no longer working; but the idea is still sound. http://www.pcworld.com/article/209333/how_to_hijack_facebook_using_firesheep.html

    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 '16 at 00:33
  • 2
    Not so dangerous if contents of that website are 100% public. – defalt Nov 29 '16 at 07:47
  • @user334283 unprotected 100% public websites are great only for malware injection and tracking which pages you browsed. – Z.T. Nov 29 '16 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. – Rod MacPherson Nov 29 '16 at 15:50
  • @RodMacPherson These are MITM attacks which you have mentioned and they happen in https too. The potential danger is if you yourself give your private information on http. Websites whose contents are 100% public are no used to an attacker which he obtains by sniffing. https only decreases the probability. – defalt Nov 29 '16 at 16:21
  • Indeed my mentioning of SSLSTRIP confused the issue a bit. It doesn't work when users check if they have HTTPS. – Corporal Touchy Nov 29 '16 at 16:51

4 Answers4

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.

crovers
  • 6,381
  • 1
  • 20
  • 30
DepressedDaniel
  • 1,240
  • 7
  • 8
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.

Steffen Ullrich
  • 201,479
  • 30
  • 402
  • 465
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 ;-)

S0AndS0
  • 387
  • 1
  • 3
  • 12
  • So you're saying you tunnel everything to a private server for extra security? – Corporal Touchy Nov 30 '16 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 02 '16 at 03: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 '16 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 '16 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.

IEnjoyEatingVegetables
  • 149
  • 7