I understand that it is bad to send passwords in plain text over the wire because somebody can look at it and clearly steal your information, and that the solution is to use HTTPS because the information is encrypted between end points.

If you are on an untrusted network where other people can see traffic to/from your machine (via something like wireshark), or the receiver is on an untrusted network, this makes perfect sense.

But if you are on a locked down, secure network and the receiver is also on a locked down (but separate), secure network, what are the ways that someone can get at your unencrypted HTTP traffic?


7 Answers 7


They can snoop on the traffic between the two secure networks. They can redirect traffic to their own network rather than the secure network.

  • Can you elaborate a little bit about those two methods? I am unsure how somebody can get access to either snoop or redirect traffic between two end points without having some kind of special access to the routers owned by ISPs in the internet core. Perhaps my entire understanding of how it all fits together is a bit off.
    – John Cage
    Nov 1, 2011 at 20:37
  • 2
    The methods are varied. One way would be to be an employee of one of those ISPs. Another way would be to break into those routers. Yet another way would be to use DNS cache poisoning type attacks to redirect the traffic to the attacker. There are many, many ways to do it. Nov 1, 2011 at 21:41

I see a reason to secure a trusted network is to protect from insider attack. If sensitive data is being passed within a network in plain text, insider can sniff and analysis the traffic.



A rogue access point or switch is a definite possibility. For example, say a user sits in a cluster of 8 or so cubicles. All of these cubicles are plugged into a switched tucked away behind one of the cubicles walls. If an employee found this, he could bring his own switch from home and stick it between the company switch and the panel on the wall. Then all he would have to do is plug his computer into his own switch and set up port mirroring. Now all of the traffic from the cubicle cluster would be mirrored to his computer, which could then be further sniffed and analyzed.

Another employee could bring a wireless AP to work and share the ssid of his unencrypted signal with his coworkers. He could then sniff and analyze the traffic of his coworkers that are connected to it.

Or an employee could execute some form of ARP poisoning and perform a Man in the Middle attack.

But all of that depends on how "secure" this network is.

  • MITM bridge on any cable. A pwn2own device is all one needs.
    – ewanm89
    Nov 1, 2011 at 21:15

You can't lock down and secure the network.

It is precisely this myth that allows hackers to do bad things. People put all their defenses on the edge, but not inside. Once the hacker gets inside, they can freely break into absolutely everything inside.

You have to assume that hackers will get inside, and plan accordingly. That means spending less on the edge, on more on the inside.


There are several attack methods that apply even if both endpoints are on a "locked-down, secured" network segment:

  • DNS hijacking. Attackers may be able to poison or spoof DNS records for the server, thus causing the client to connect not to the legitimate server but to an illegitimate server.

  • BGP hijacking. Attackers may be able to attack BGP to cause packets to be routed, not to the legitimate server, but rather to the attacker.

  • Eavesdropping. Attackers may be able to eavesdrop on the data as it traverses the path from the client to the server. Even if the client and server are each individually on a network segment that does not allow eavesdropping, the attacker may still be able to eavesdrop on some intermediate hop halfway in between the two endpoints.

In each of these attack scenarios, all security is lost if you are not using any form of end-to-end crypto. Securing the network at the two endpoints does not stop any of these attacks.

P.S. There ain't no such thing as a secure network. I don't care how much "locking down" you do. When you throw around phrases like "locked down, secure network", it makes me think of marketing hype: e.g., maybe you've been fed some marketing documents and are repeating them. If so, beware that reality doesn't match the nice-sounding phrase.

(Other phrases that should raise red flags for you include "unbreakable", "military-grade cryptography"/"military-grade security", "patent-pending encryption algorithms".)


If by secure network you do mean one where every link is a point to point secured connection from the computer to the switch, with all devices authenticating to each other and strong encryption used, then you do limit the compromise of data, however you would still need to monitor/manage the network admins, as they may have the ability to intercept communications.

That type of network only exists in certain highly restricted environments, more commonly you will find a network with perimeter security, or one using a secure domain - which means once you are inside it is much more open.

Switched networks make it harder to sniff data, as it should only pass from source through switch to destination. But switches can be persuaded to pass on traffic.

tl;dr So useful interception points:

  • switches
  • communication link between the two networks
  • in cabinet at the ISP

or even

  • from compromise of either host

I think most people are not seeing the point in here. True there all sorts of attacks you can try, but you mention something in your question.

But if you are on a locked down, secure network and the receiver is also on a locked down (but separate), secure network, what are the ways that someone can get at your unencrypted HTTP traffic?

I think the main concern in here is an insider threat. Anyone hooked up to your "secure network" could just fire up a sniffer and log traffic, then capture those unencrypted credentials. Of course (as an IT guy) you should be aware that there is no such a thing as a "secure network".

You must log in to answer this question.