This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

NSA sniffing and encryption

1

With all the NSA sniffing going on, encryption should be the default for any communication, although that does not prevent sniffing data in many cases (google, facebook, etc. handing over data 'voluntarily').

On the other side, using encryption per default will create (besides technical and management overhead) massive problems for network troubleshooting and tools like Wireshark.

I wonder what will be the future of network troubleshooting in this context and how network troubleshooting tools (Wireshark and the like) will look like in 5 years, considering

  • a (massive) shift to encrypted communication (Problem: can't read payload)
  • the ever increasing trend to move data and applications into clouds (Problem: don't have access to all communication)
  • the ever increasing network speeds (100 Gbit/s ethernet available). (Problem: hard to record data at full speed)

What do you think how this will have an influence on network troubleshooting and tools?

Regards
Kurt

asked 15 Aug '13, 08:18

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 15 Aug '13, 08:52


6 Answers:

1

The massive shift to end-to-end encryption will have a greater impact on surveillance tools, Deep Packet Inspection based solutions, Intrusion Detection, and the like. These simply wont work or will see dramatically reduced functionality on the subset of traffic that is encrypted. I think the impact on Wireshark will be far milder.

Wireshark has a major user base that isn't very visible I suppose. It is used extensively by all network equipment vendors such as those developing protocol support for Mobile technologies and the like. This segment will see no impact due to encryption of user traffic. So Wireshark is going to be as strong as ever in this major segment.

Casual users without control of end points trying to use features like "Dump HTTP Objects" are going to see these features vanish. Those who control end points can still use Wireshark the same way by instrumenting their applications to save either the keying material or plaintext.

I think the future for network tools are traffic and flow analysis. Network zones containing the most important assets will probably be under "Network Security Monitoring" tools such as those included in the Security Onion distro.

answered 19 Aug '13, 03:37

VIVEKRJG's gravatar image

VIVEKRJG
162
accept rate: 0%

edited 19 Aug '13, 03:39

These simply wont work or will see dramatically reduced functionality on the subset of traffic that is encrypted.

ACK

I think the impact on Wireshark will be far milder.

Well, I'm not quite sure. Yes, Wireshark (and similar tools) are very useful even if you cannot read the payload. However, based on personal experience, a lot of problems are within the client/server communication (at the application layer) and you won't be able to diagnose those problems with more encryption in place (if that happens anyway).

Those who control end points can still use Wireshark the same way by instrumenting their applications to save either the keying material or plaintext.

Besides some browsers, which client application do you know that dumps session keys? I know virtually none.

So, this will be a bigger problem than it is already today. Sure, some applications can be configured/tricked to accept a intermediate certificate of an SSL proxy. But, it's a hassle today and it will get worse with more encryption in place.

I think the future for network tools are traffic and flow analysis.

That's also what I think. So, there should be good tools available for that special purpose. I know there are good commercial tools already available, but I don't know (yet) a good open source tool for it. Should that kind of functionality be part of Wireshark?

Network zones containing the most important assets will probably be under "Network Security Monitoring" tools such as those included in the Security Onion distro.

ACK

(20 Aug '13, 08:17) Kurt Knochner ♦

1

I think that with growing complexity we will see a point where companies will have different strategies regarding encryption depending on where the traffic is going to go to:

  1. external communication will be encrypted. Site-to-site for company-owned locations with VPN concentrators doing IPSec or OpenVPN; email (or whatever messaging will replace it) will probably be end-to-end from user to user

  2. strictly internal communication will often be forced to be plain text, just for the sake of being able to troubleshoot. I've already seen sort of this happen when customers decided against link aggregation and implemented RSTP instead, because it is easier to capture a single active link than to deal with multiple aggregated links.

Even if a lot of communication is encrypted we will still troubleshoot. Very often the problems can be seen in layers 2-4 (especially TCP), so things like HTTPS do not matter that much. There is an old rule I do network analysis when it comes to encryption: "if the encrytpion is the problem, things usually go wrong when the encryption is being negotiated. Once the encrypted tunnel is up, it just works."

And if you really need to look into an encrypted tunnel you'll need to man-in-the-middle it in some way, or decrypt it with the master keys (which will be a problem when it comes to deploying forward secrecy, I know).

answered 19 Aug '13, 10:04

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

I've already seen sort of this happen when customers decided against link aggregation and implemented RSTP instead, because it is easier to capture a single active link than to deal with multiple aggregated links.

Interesting. My experience is rather the opposite. Nobody thinks about troubleshooting (and/or security) until the first incident, just to realize that the current infrastructure does not help to analyze a problem.

Even if a lot of communication is encrypted we will still troubleshoot.

I'm sure we will, but the way troubleshooting is done will have to change.

There is an old rule I do network analysis when it comes to encryption: "if the encrytpion is the problem, things usually go wrong when the encryption is being negotiated. Once the encrypted tunnel is up, it just works."

Regarding encryption you are right. However, the problem it's not the encryption itself, the problem is failing client/server communication that gets tunneled over a working encrypted communication.

And if you really need to look into an encrypted tunnel you'll need to man-in-the-middle it in some way, or decrypt it with the master keys (which will be a problem when it comes to deploying forward secrecy, I know).

See my comment in the answer of @VIVEKRJG for this. Yes, it's possible and it's hassle today (due to client software restrictions) and it will get worse with more encryption in place.

Sounds like you don't expect any challenges (for troubleshooting tools) coming from encryption, cloud services and network speeds, right?

(20 Aug '13, 08:28) Kurt Knochner ♦

No, actually I don't expect more than the usual challenge we already face in today's networks. I think that most internal traffic will stay unencrypted - in many cases not because the company wants to support troubleshooting, but simply because implementing stuff like SSL often requires additional steps when setting up servers/applications and admin's are lazy :-)

(20 Aug '13, 12:36) Jasper ♦♦

Or the admins have way too much work to do and just keeping the major stuff running takes all available time :-)

(21 Aug '13, 01:21) grahamb ♦

•the ever increasing network speeds (100 Gbit/s ethernet available). (Problem: hard to record data at full speed)

Unless some of the technices used by NTOP like Direct Nic Access PF_RING or similar is GPL:ed and incorporated into libpcap we might see a move to use specialised HW to do high speed capturing. I think the problem may be more of high speed filtering actually as saving 100Gbit/s to disk is a challenge in it self.

(21 Aug '13, 08:37) Anders ♦

is GPL:ed and incorporated into libpcap

libpcap is BSD-licensed, so presumably you mean "un-GPLed" - GPLed code can't be in libpcap. It might be possible to add PF_RING support to libpcap, although I'm curious whether PF_PACKET sockets with TPACKET_V3 would work as well (that also needs non-GPLed code to support it; it's on the list of things for me to look at in my Copious Free Time(TM)).

(21 Aug '13, 13:17) Guy Harris ♦♦
(23 Aug '13, 06:18) Anders ♦

If I correctly remember the tcpdump-workers discussion of that patch, it's based on some code from Daniel Borkmann, which was, in turn, based on sample code from Chetan Loke (the guy who created TPACKET_V3, as I understand it), and that code is GPLed. That makes the code in question GPLed, and thus not able to be part of libpcap.

(23 Aug '13, 10:30) Guy Harris ♦♦

Perhaps the ticket should be updated/rejected with that information then. Doest the other two patches suffer from the same problem?

(24 Aug '13, 00:52) Anders ♦
showing 5 of 8 show 3 more comments

1

A few thoughts on encryption:

  • I would say that most packet-level troubleshooting occurs within local networks that aren't crossing the Internet or a WAN. In such environments, there isn't much motivation for encryption. Encryption of important/sensitive data over a WAN or Internet is already best-practice and very common for enterprises.

  • In many cases with Wireshark you're troubleshooting at layers before encryption occurs. In such cases, the encryption makes no difference.

  • Unless there's a need for a drastic change, and unless businesses/application developers see that need clear as day, it's going to take a long time for end-to-end encryption of common applications that need troubleshooting to ever see the light of day. IPv6 and VoIP are great examples of technology which are superior to what we have now, but not so much so to justify an overhaul so the changes have come very, very slowly.

For the problem of bandwidth and network usage increasing, a few other thoughts:

  • Network architecture in the mobile/telecom space has taken a lot of steps over the last few 3GPP releases to isolate control/signaling traffic (the stuff you'd likely want to troubleshoot with) from the simpler, high-bandwidth user-plane data flows, logically and in most cases physically on the wire. This approach allows for the capture of signaling traffic relevant for sessions that could be carrying Tbps's of bandwidth by capturing on very low-bandwidth links.

  • The traffic capturing and aggregation/filtering/sorting technologies out there are keeping up with increased bandwidth pretty well. The quick rise of companies like VSS who sell dedicated aggregators for filtering high-bandwidth links into isolate flows for analysis, the move of vendors like Cisco to performing SPAN on their routing platforms in hardware rather than the historically processor-crippling methods they'd used in the past, the advancement of new in-line capture methods such as JDSU's Packet Portal (SFPs in a router or switch that can intelligently self-mirror traffic to an analyzer), off the top of my head are just a few examples of the market rising to meet these kinds of challenges.

For clouds, all I'll say on that is that it creates a few unknowns in your troubleshooting. That's almost always a reality, and would require you to call the cloud's operator for assistance possibly. No different than troubleshooting a roaming scenario in mobile.

answered 31 Aug '13, 19:48

Quadratic's gravatar image

Quadratic
1.9k6928
accept rate: 13%

I share most of your views regarding encryption, yet I still believe that there will be a broader shift to encryption, even on the LAN, as the default mode of future applications will be encrypted, also as a lesson learned from the NSA 'scandal'. If that creates a problem for network troubleshooting depends on the protocols used, the applications and many more factors. However, I tend to believe that it will make quite a few thing more complicated. Even today I often have problems to get the server keys for TLS decryption, due to incompetence, security issues, etc. With DHE ciphers it's even harder, unless you have a client that reveals the sessions keys (not that often in the wild). With more encryption in place (which is good!) it will get even harder.

Regarding network usage and bandwidth: Yes, there are already good commercial (hardware) solutions that are able to filter and/or store capture data at high speeds. But what about open source tools like Wireshark? Will they be able to compete in that field, or do they need new, unique features (like more automatic 'expert analysis modules', automatic flow analaysis, etc.) to be able to still deliver a good value for users in the future?

(03 Sep '13, 00:08) Kurt Knochner ♦

I view Wireshark as a receiver, or user of those kinds of network capturing technologies rather than as a competitor. Those tools specialize in filtering or sorting flows out of high-capacity links and forwarding the right flows to the right analyzers. They do filtering at very low layers, typically no higher than L4, relying on analyzers (Wireshark, Snort, etc.) to receive the smaller flows to do deeper dives on them.

One area that the open source community still needs to fill, whether as an evolution of Wireshark or as something else, is flow analysis and performance management counters built at that deeper level. Right now we have people digging into Lua or perl/tshark scripting, calling Wireshark dissectors to build application-level counters for all sorts of metrics that no open-source tool other than Wireshark can dissect. When I see the same or similar task being tackled independantly by all sorts of people in the industry (the task of automating packet captures and scanning through time intervals for a count or averaging of a given value of a given field of a given protocol that only Wireshark can decode or count, for the purpose of reporting), it speaks to a need for a new tool or a revisioning of Wireshark's scope as an ad-hoc, session-level analyzer.

So in short, Wireshark is the microscope for a session, dedicated capture/filter/aggregator tools on high capacity links are the birds-eye view that can feed the microscope something to start looking at, but there's something missing in between for analysing application-level flows for the purpose of performance management and reporting.

(03 Sep '13, 15:43) Quadratic

One area that the open source community still needs to fill, whether as an evolution of Wireshark or as something else, is flow analysis and performance management counters built at that deeper level.

Yep, that's what I'm missing as well.

it speaks to a need for a new tool or a revisioning of Wireshark's scope as an ad-hoc, session-level analyzer.

I agree, that (real-time) monitoring features within Wireshark would be interesting for some people.

(03 Sep '13, 23:47) Kurt Knochner ♦

0

I've had the United States Army Intelligence Center at Fort Huachuca, Arizona, swarm my Wide Are Network after I ran a port scan on a suspicious IP (just with the intention of scaring them away) ... within 30 seconds the WAN was filled with AISRC addresses (that's the Army's Intelligence Service Research Center, according to WhoIs)

They did nothing but watch for about 30 mins. No unusual scans or traffic because I had no nefarious intent. I honestly think encryption will only make them think you have something to hide. They don't want to work any harder than they have to work, but an encrypted connection that stands out might very well make the analysts hope to catch someone important to get promoted.

Make yourself as boring as possible.

answered 30 Aug '13, 04:24

AdrianThePhotog's gravatar image

AdrianThePhotog
112
accept rate: 0%

edited 30 Aug '13, 04:24

swarm my Wide Are Network after I ran a port scan on a suspicious IP (just with the intention of scaring them away)

To scare away the NSA with a port scan sounds like the second most clever idea to me. A better idea would be to steal some secrets documents and publish them. That would really pi.. them off. I hope nobody plans to do such a thing in the near future!!

I honestly think encryption will only make them think you have something to hide.

Well, the only use of encryption is to hide something and if the wish to hide something is suspicious in itself, we should all have glass walls in our homes. After all: If you don't have to hide something .... ;-)

but an encrypted connection that stands out might very well make the analysts hope to catch someone important to get promoted.

How does one encrypted connection stand out more than another, if it is not terminating in the Al-Qaeda headquarters?

Make yourself as boring as possible.

That's not a very clever advice, because that's the tactics of sleeper agents. Due to that they will head for the boring people first!

I wish a good night. And please remember, there is always a big brother to care for you. :-))

(31 Aug '13, 14:58) Kurt Knochner ♦

I wasn't trying to scare away THEM. Jesus. Just some other suspicious IP. It wasn't one of theirs. They showed up because of that scan. Hopefully that makes more sense.

I think you really took the rest of what I said too far. But the truth is that I notice unusual encrypted connections. I've been doing this for 10 years and I know when someone is waving around more security than normal. You're better off hiding it in ways that are not as obvious. There's a reason book ciphers are becoming popular again: they don't stand out at all.

So those are my thoughts. I guess I was a bit more scatter-brained before. Sorry. =) I'm at least a little tiny bit clever after all these years, I swear! (only a little)

(31 Aug '13, 18:27) AdrianThePhotog

I think you really took the rest of what I said too far.

That was just a bit fun. I should have marked it with <fun></fun> tags ;-)

But the truth is that I notice unusual encrypted connections.

O.K. how do you define unusual encrypted connections?

I've been doing this for 10 years and I know when someone is waving around more security than normal.

Interesting. How do you identify that, based only on the encrypted communication? I mean what is the criteria within the encrypted data?

There's a reason book ciphers are becoming popular again: they don't stand out at all.

book ciphers in electronic communication? Where (in practice) have you seen that lately?

BTW: Regarding the AISRC addresses on you WAN. You said:

Just some other suspicious IP. It wasn't one of theirs.

That could have been faked addresses to scare you away ;-) I do that sometimes to frighten script kiddies if they scan my network :-))

Regards
Kurt

(01 Sep '13, 01:20) Kurt Knochner ♦

Ahh, okay. I define all communications through what I see normally. It's like seeing a stranger. Google, Akamai, and FaceBook all have predictable protocols that they "like" using. They respond to new webpages the same, and when they change, it's usually something I'd have honestly expected sooner. (like the transfer to https by facebook)

All I can say about book ciphers is that I've met a lot of crypto-nerds over the years, and I know a few people who'd rather not have their vices tracked, or used against them later in court. The idea isn't to be so secure as unnoticed. They work.

The AISRC stuff could have been to scare me away, but I hadn't heard about the Iran nuclear hack yet though, and it was the w3af that I read later was also used there.

Who cares? My point was that there is security in being unnoticed. You can't hack, crack, or spoof being invisible in a crowd because it seems like you're talking about food on twitter.

(01 Sep '13, 15:39) AdrianThePhotog
1

I accept that as a final statement for this answer ;-)

(02 Sep '13, 04:18) Kurt Knochner ♦

0

The only other reason I believe the AISRC stuff is that my father used to be a programmer for TRW, as a mathematician who wrote code for them. Since he now resides in Israel, I'm pretty sure SOMEONE would know if I did anything illegal. LOL

answered 02 Sep '13, 14:27

AdrianThePhotog's gravatar image

AdrianThePhotog
112
accept rate: 0%

0

TNow part of Northrop-Grumman, they were still just TRW back when he worked for them at the end of the Cold War: http://en.wikipedia.org/wiki/TRW_Inc.

He was let go a couple years later.

edit: he's a mathematician who worked on N2 charts for missile flight systems: http://en.wikipedia.org/wiki/N2_Chart

(he just played Tetris most of the time I was there- it was the 80's)

answered 02 Sep '13, 15:31

AdrianThePhotog's gravatar image

AdrianThePhotog
112
accept rate: 0%

edited 02 Sep '13, 15:56