<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 10, 2013 at 2:08 PM, Neal Rhodes <span dir="ltr"><<a href="mailto:neal@mnopltd.com" target="_blank">neal@mnopltd.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
So, picture two servers which talk to each other within a corporate LAN/WAN in a data center, and worker bees in an office location elsewhere in the same city, who only have hard-wired LAN access, and assume they have IP connectivity to the data center. <br>
<br>
And picture that these two servers have an unsecured http protocol they talk over. <br>
<br>
And picture a worker bee with too much time on their hands and the intent to hijack this. <br>
<br>
If said worker bee managed to get WireShark or similar installed on their workstation, they could sniff whatever that hard Cat5 cable can see. Which, assuming it is connected to a switch, not an old-fashioned hub, is pretty much zilch. Basically their own traffic. <br>
<br>
They can't see most traffic to/from the guy in the next cubicle to the servers, because the switch doesn't normally let them see it. For performance reasons, it isolates each LAN port. They can't see any of the server-server packets, because the two routers in between behave like switches, not hubs, and don't route local server-server traffic. <br>
<br>
So, assuming that Wifi is not available, it seems like the LAN sniffer attack vector based on seeing what is happening is pretty much moot. That is not to say that actively probing isn't rewarding. <br>
<br>
Let's take it one step farther: presume that it is trivial for these two servers to switch from talking http:80 to each other and start talking https:443 to each other. From the perspective above, this is a negligible practical improvement. It only gets interesting if we imagine someone able to get onto the local LAN in the data center. But even then, presuming that is also a switch, they ain't gonna see spit. <br>
<br>
Let's take it one step farther: assume that they could in fact compromise the data center switch, and capture a pile of the https traffic between servers. Would we logically assume that given today's technology that they could manage to decrypt it with enough CPU and time? <br>
<br>
Thoughts? <br><span class=""><font color="#888888">
<br>
Neal Rhodes<br>
MNOP Ltd
</font></span></div>
</blockquote></div><br></div><div class="gmail_extra"></div><div class="gmail_extra"><br></div><div class="gmail_extra">You'd be surprised at how much stuff comes through a switch as broadcast traffic, and there's always tools like ettercap which can overflow the switch MAC address table, forcing it to revert to "hub" mode (in addition to other MITM attacks).<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">It is not feasible to decrypt https traffic unless you have access to the private keys, which are hopefully stored securely on the remote web server somewhere. Or you can perform a man-in-the-middle attack where the user accepts the invalid certificate (which is entirely possible). Even the NSA needs the private keys, which is what those secret court orders are all about.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">The "enough CPU and time" part of your question is not really relevant. The answer to that question is "yes", because it dismisses the two most important constraints in evaluating any cryptography. CPU and time are THE most important constraints, as anything given enough time can be broken, but we're talking on the order of billions of years. The most important qualifier there is "reasonable within your lifetime".<br>
</div><div class="gmail_extra"><br><br clear="all"><div>❧ Brian Mathis</div>
<br><br></div></div>