8

What are the risks of using HTTP instead of HTTPS assuming that there isn't any rogue hacker sitting on my personal WiFi network waiting to sniff my traffic?

Can a hacker sit in his boat in the middle of the ocean to tap into the network lines and sniff my packets? Or is it not possible (or extremely hard) to do so once the packet leaves my network?

I always have this mindset that for an average user with no incentive to target an attack against, there is a lower risk of using HTTP.

  • 1
    Would you log in to your bank's website over HTTP? Average users use online banking too. Why would an average user not be attacked? – Jeroen Apr 16 '15 at 6:26
  • A very short answer: NSA has gigantic datacenters to store all unencrypted traffic. When you send your packet to destination using WWW, it has a long way go, and can be stored anywhere between source and destination. If you encrypt it, it still can be stored but worthless unless decrypted. – ferit Dec 12 '16 at 0:12
  • Worth noting that trusting the local network isn't usually a good idea. There are lots of potential ways that your local network could be compromised, whether by hacking your router or installing malware on another machine on the same network. – Ajedi32 Jan 19 '17 at 18:13
9
+25

Assuming your local network is secure, the average script kiddie / hacker with minimal resources would not be able to tap into the connection even when using plain unencrypted HTTP. That doesn't mean using plain HTTP is risk-free. Your data could still be captured and logged or freely modified by:

  • Your ISP and your own government
  • ISPs and governments in countries your traffic is routed through
  • Anyone capable of launching a BGP route hijacking attack

And, of course, any of the above could share the data with third parties of their choosing, or even give these outside parties direct access to your network traffic.


A few examples:

Some ISPs are known to inject JavaScript into HTML pages. This could be additional advertising or tracking, or custom notifications like in the case of Comcast recently.

I live in Finland, and a lot of the Finnish internet traffic is routed through Sweden. In 2009 Sweden passed a law allowing the Swedish intelligence agency FRA to monitor all internet connections that cross the border. This means Sweden is both technically and legally able to use mass surveillance on Finnish internet users. FRA has also been reported to co-operate closely with NSA and GCHQ, and they are likely to share data.

In 2013 the surveillance software company Hacking Team orchestrated a BGP hijack in co-operation with the Italian government and a hosting company. Similar route hijacks could easily be used to tap into HTTP connections from anywhere in the world. BGP hijacks or "leaks" are not rare. The @bgpmon Twitter account, among others, tracks and reports these types of events. Often the events are attributed to misconfigurations and human error, but in most cases it's not possible to know for sure. Quite often the culprits are individual ISPs in China or similar countries, and there's no guarantee that the ISPs themselves weren't the target of a hack.


Besides security, there are other reasons to use HTTPS. SPDY and HTTP/2, which are new versions of HTTP with less overhead, are only supported over TLS in most implementations. Many JavaScript web technologies are also only available to HTTPS websites, e.g. Service Workers and the Location API.

  • While not arguing with the bulk of your post, I would say that if WiFi is involved, the assumption in the first few words of your answer probably shouldn't be relied on unless you're running Enterprise level encryption. – Gwyn Evans Dec 11 '16 at 11:42
  • @GwynEvans I completely agree. However that's exactly the scenario the question is about. – jupenur Dec 11 '16 at 11:54
  • Good point - I didn't read the original question well enough! Sorry about that! – Gwyn Evans Dec 11 '16 at 12:00
  • @jupenur: I am working on the assumption that if the internet provider or the gov wanted my data, https/ssh wouldn't stop them. I thought these encryptions were broken (especially if you can isolate the data and through computing power at it with infinite retries), am I wrong? I might need to ask this as a separate question. – VSO Dec 11 '16 at 16:32
  • 1
    @VSO I'm not an expert on NSA's capabilities, but I definitely wouldn't call HTTPS broken. When implemented correctly, I'm pretty confident most governments wouldn't have the resources to decrypt TLS traffic, especially when there are much better ways to get the same end result. But yes, I think it's a bit off topic. – jupenur Dec 11 '16 at 16:38
4

Apart from the technological hurdles of getting a tap on the intercontinental lines that could actually read the data, the scenario you provided is indeed possible. If you use HTTP instead of HTTPS your data is travelling as clear text from end-to-end, so your ISP, anyone inbetween and the ISP of your destination host can read or even modify your data if they really wanted to.

The EFF has a nice widget detailing who can see what with HTTP/S: https://www.eff.org/pages/tor-and-https

2

HTTP is an inherently "trusting" protocol: it contains little or no built-in security. This means that it is susceptible to the following:

  1. Traffic monitoring Anything transmitted over HTTP can be intercepted and read by anyone connected to any network sitting between the source device and the target server.
  2. Traffic redirection and manipulation With little work, your traffic could be rerouted to a server controlled by a third party without you being able to notice anything. once the traffic has been redirected, it can be read but also changed: someone could inject any kind of data, including script, into the stream. Unless you have some external way to validate what you obtained through the HTTP connection, there is no way to be sure it came from the "right" source.

There are also a variety of less obvious attacks that could be performed if you routinely use HTTP instead of HTTPS (like URL redirection attack).

  • What does #1 even mean - let's say someone wanted to intentionally read the opening poster's traffic - how would he do it? Isn't routing random? What does "little work" mean - how common is it? Can they be anywhere in the world? – VSO Dec 11 '16 at 3:04
  • URL redirection attacks have nothing to do with HTTPS use. URL redirection attacks target web applications vulnerable to open redirection, not the HTTP protocol. – jupenur Dec 11 '16 at 11:25
1

Suppossing that an attacker is already inside your wireless network, you must know that even your https connections can be sniffed using techniques like sslstrip. The good practice to avoid this technique is to create all your bookmarks and shortcuts using the string https:// at the beggining. If you try to access directly to a page putting in the bar for example https://outlook.com the connection can't be victim of sslstrip. If you put only for example outlook.com without using https prefix you can be hacked even in a ssl connection and your data can be sniffed in plain if a skilled hacker is on your network.

How sslstrip works?

A lot of websites are using HSTS (Http Scrict Transport Security) which consist basically in redirect a plain http request to a https to be secured. For example, you can notice if you enter to outlook.com that a redirect is done and you will see the site with the green lock and using https. This is because HSTS which is configured and highly recommended to put on the websites. But in this scenario, there is one request to http... that first request is what sslstrip takes to do "its magic". The attacker which has done a MITM (Man in the middle) first, serves to the victim the page in plain http and he does the https connection to the real server. The victim could notice there is not green lock in the bar... but believe me, you don't notice that, so is very effective.

Some sites like facebook can't be sslstripped because since some time ago, the browsers have an internal list of some sites which are known to use https so it no matter if you ask to the brower for http://facebook.com , the browser is going to ask directly to https://facebook.com so there is no initial http plain request and sslstrip can't work. But there are not too many sites on that browser's lists... I guess the sites should be paying to the browsers to be in that list, not sure about this. So this only affect to "big sites" like facebook and some others which are world wide known.

So, if the hacker is already in your network, is a question of time to sniff something useful. Try to protect your first level first (to protect your network to be broken). If is not possible and the hacker is already in the network, then, use always https:// on your bookmarks and shortcuts... it makes the difference... believe me.

Here is a video more explicative about sslstrip

  • If OP is under an sslstrip attack he's not using https anymore. Also the question supposes the attacker is not in his internal network – Mr. E Dec 14 '16 at 0:44
  • Ohh I understood the opposite... with a hacker inside the network... that's because of my explanation :) – OscarAkaElvis Dec 14 '16 at 9:12
  • Still nice to know. I hate how much stackoverflow pigeon-holes answers. – VSO Dec 14 '16 at 12:53
  • I'm glad to be useful to somebody even being wrong with the question. – OscarAkaElvis Dec 14 '16 at 14:28
1

My favorite answer to this question from WAHH:

eavesdroppers may reside:

  1. On the user's local network
  2. Within the user's IT department
  3. Within the user's ISP
  4. On the Internet backbone
  5. Within the ISP hosting the application
  6. Within the IT department managing the application

Stuttard, Dafydd; Pinto, Marcus. "The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws" (p. 169). Wiley. Kindle Edition.

  • Curious: when you use Kindle Edition - does referencing a specific page number make sense? Doesn't it depend on the font used by each reader? – techraf Dec 15 '16 at 0:06
  • Nice to have a summary! – VSO Dec 15 '16 at 13:00
  • @techraf you're right. The page number varies but as soon as I copy something on Kindle this message comes with it. – Zatara7 Dec 15 '16 at 22:18
1

In this answer, im going to assume that the partners that the partners that the OP, or the communication target, does have some business relation to, is enroute without any tampering, or is a government of that location, is trusted. This means, in the bank example, the following parties is fully trusted:

  • The OP's own network and all parties involved in that, for example his family.
  • The OP's landlord, which has access to the communication lines in the building.
  • The OP's ISP, and all ISPs up to, including the backbone operator.
  • Any government agency operating in the OP's location.
  • The Banks ISP, and all ISPs up to, including the backbone operator.
  • The Banks landlord, which may, or may not, have access to the communication lines.
  • The Banks own network and all parties involved in that, for example IT admins.
  • Any government agency operating in the Bank's location.
  • And finally, any government agency operating in any country that is enroute to the target location, considering that any tampering of any routers enroute to the target location has NOT happened, even if by request by that government.

On security, I also assume that:

  • Any equipment owned by OP is secure.
  • Any equipment owned by bank is secure.
  • Any equipment owned by government is secure.

The reason I make these assumptions, is to isolate the cases where a eavesdropping or modification of traffic poses a security risk, rather than just being a nuisance for the user. If a government intentionally sniffs up OPs credit card number, it does not pose any risk for the OP, because the credit card number will not give the government any greater access, the government could with one single phone call seize all the money from OPs account anyways. Same with the ISP, the ISP who modifies traffic to insert advertising, is not gonna make any use of OPs facebook password anyways.

Another important thing is to assess if a organization is able to keep their equipment safe from external attackers. Here, I assume the OP is knowledgeable and can configure his own routers and firewalls securely, thus I set the OPs equipment to secure. This means any equipment owned by the OP cannot be remotely compromised. The banks equipment is obviously configured securely. And the governments equipment used to store eavesdropped data or similiar info, is of course configured even more securely than the bank.

Considering this trust assessment, this means that there is few attack vectors to attack HTTP over a wired network.

The only attack vectors I can see is the following:

  • Eavesdropping on publicity accessible wiring. An example would be listening on ADSL signals from a air-hanging telephony wiring.

  • Breaking and entering into local equipment rooms. For example equipment rooms owned by the ISP or the landlord. Larger equipment rooms serving a larger area, normally have severe alarm protection, guards nearby if not onsite and high security, but local equipment rooms are often weak security, sometimes a locked rack cabinet in a cellar with exposed wiring that can be spliced into and eavesdropped without affecting the lock on the rack cabinet.

  • Remotely hacking into local equipment. Landlord equipment for smaller landlords are often configured insecurely with bad passwords, in some cases this also apply to ISP equipment that is local. A router that OP hired from the ISP and does not have any administration capabilities by the customer, might also be suspecible to easy hacking.

  • Eavesdropping on wireless links with weak/no encryption that the OP cannot control over. This can apply to a point-to-point link set up by a ISP to bridge a area that is difficult to route any physical cables over. This can also apply to certain mobile links.

  • BGP manipulation by annoucing routes for networks that somebody don't own. This is the only risk actually worth considering. Some ISPs may also use methods that prevent unauthorized people from annoucing availability for the ISPs networks. Such security solutions may include, but are not limited, to restricting BGP traffic from any customer owned equipment.

-1

In addition to what some of the answerers pointed out, most secure sites (e.g. banking web site, etc.), will not even allow you to access secure content through their sites via http. So, using http is not even an option with these sites - you have to use https.

-2

You can sniff HTTP packets using tools like Wireshark and it's like a walk in the park to read your data packets. An attacker can intercept your data packets, modify it and forward it. For example: you ask your bank to pay you - the attacker modify this packet and ask the bank to pay him.

I don't understand what you mean by

HTTP in your Wi-Fi network.

Don't you want to access the world wide web?

  • 2
    the OP asks if attacker can sniff your http packets if he is not in the same (sub)network as yours. – elsadek Dec 11 '16 at 11:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.