I have heard many times that HTTPS should be used for transferring private data, since HTTP is vulnerable to eavesdroppers. But in practical terms, just who is capable of eavesdropping on a given surfer's HTTP traffic? Their ISP? Other people on the same LAN? Anyone who knows their IP address?
Easy - just follow the cable from your PC to the server.
This is maybe specific to Austria, but it probably looks similar all over the world.
let's assume we've got an DSL user:
- PC -> Ethernet -> Modem
Anybody with access to the local infrastructure can sniff the traffic
- Modem -> 2-wire-Copper -> DSLAM
Anybody with access to the copper infrastructure and equipment which is able to decode the data can eavesdrop. Most of this wiring is relatively unprotected and easy to access if you know where to look, but to actually decode the data you'd probably need some very specific equipment.
- DSLAM -> ISP infrastructure -> ISP core routers
Most DSLAMs are connected via Fibre to some sort of Fibre Ring/MAN to routers of the ISP.
There have been stories in Germany where supposedly three-letter-agencies from the U.S. of A eavesdropped on traffic of a Metropolitan Area Network. There are off-the-shelf devices which can do this, you just need the right budget, intent and knowledge of the local infrastructure.
- ISP core routers -> BGP -> Target AS
Given that the destination server is not in the same Autonomous System as the user is, the traffic has to be sent over the "Internet". If you're going over the Internet, to use a quote from Snatch, "All Bets Are Off". There are so many nooks and crannies were a malicious operators could attach themselves, that you're best assuming that all your traffic is going to be read.
The DHS (or maybe some other agency) actively eavesdropped on backbone infrastructure in the USA on this level.
- Target AS Border router -> ISP infrastructure -> Housing Center
- Housing Center Router -> Switches -> Server
This is how quite a few sites were already attacked. Ethernet offers no protection for hosts which are in the same (V)LAN/broadcast domain, so any host can try ARP spoofing/poisoning to impersonate another server. This means that all traffic for a given server can be tunneled through a machine in the same (V)LAN.
On a switched LAN (like most Ethernet networks), you can use ARP cache poisoning to, in many cases, eavesedrop on such traffic. Basically, you can fake the client computer out and make it think that your eavesdropping station is the router off the LAN.
On shared-media LANs-- i.e. non-switched, like wireless Ethernet w/o encryption or w/ broken encryption-- you don't even need to do that. Just listen!
At the ISP, and the ISP's ISP, and the ISP's ISP's ISP... etc, an attacker would only need to sniff the traffic. Any point in the path the traffic flows thru is subject to potential eavesdropping. There are LANs in between there, too, so there's always the possibility of eavesdropping by ARP cache poisoning, etc.
Finally, at the far end there will be another LAN, just as susceptible to eavesdropping as the source LAN.
J. Random idiot who knows your IP address isn't going to be eavesdropping on your traffic without hacking something along the way, or diverting the traffic flow from its normal path to them.
Yeah-- cleartext is bad.
If you throw Wireless into the link, anywhere along the way (WiFi card, Wireless Bridge, etc) then anyone who is even in the vicinity of the network can listen.
WEP is easilly broken, given a reasonably short period of time sitting next to a busy network, and once you're on the network, you can view everybodies traffic.
Try it out for yourself if you want. Download a program called WireShark, and ask it to capture in Promiscious mode. See what comes up!
Anything that is sensitive, confidential, private, and business related, should be sent via HTTPS. A signed certificate is not expensive, and if you're on a domain you can create your own Certificate Authority which can be used to assign certificates to encrypt traffic that will automatically be trusted by clients on the same domain.
Depending on your ISP and on whether or not your connection is shared, others on your local loop may be able to sniff all your traffic. This would usually be neighbors. This is in addition to the list of people mentioned by other answers.
Also, in addition to eavesdropping, there's also the "man-in-the-middle" attack where someone puts themselves between you and the web server in question. If you are talking SSH to the remote server, the man-in-the-middle attack won't get anywhere. If you are talking cleartext, they can act as a proxy and see everything you do.
The point is that people can listen in on your conversations even without being on your LAN or the remote LAN. ARP cache poisoning for folks on your local network (or who have hacked your local network), but also DNS poisoning to make you think you're talking to someone other than who you are. If you use HTTPS with a purchased, signed certificate, people have the opportunity to know that they're not talking to the correct server, as the certificate will be the wrong one.
See this question, your exposure using http is the same as the protocols mentioned there.
Note that you may also be exposed when using HTTPS if you haven't verified out-of-band the certificate used by the other side. That is to say, if you're prompted with a message that says the remote site cannot be verified for some reason, you may be talking not to the site itself, but to an attacker who will relay your traffic to and from the actual site, recording it all the while.
Besides all the already mentioned ways to sniff your data, an old one recently gained much more interest: playing with BGP tables. At Defcon in august 2008, Anton Kapela & Alex Pilosov demonstrated a new way to make a "BGP shunt", to divert all your traffic to a place where it normally dos not go, and (that was the main new thing in their talk) to do it without the sender or the receiver noticing.
So, even if the potential sniffer is not somewhere in the normal path of your data, they still may capture it. As the others said, encrypt.
The proper way to think is that if you are using clear-text, then anyone can access this information (public info). Be it on a network or to access an external web site. There are so many attacks and redirections that can be done that it is impossible to preview.
Because of that, only send public information (or information that is not terribly confidential) on clear text. Yes, including email.
*btw, try traceroute to any web site and see how many hops there are in the middle. Your data is going through all of them: