I’m excited to announce that Wireshark has a new home. I recently accepted a job with Sysdig, and along with that, they are now Wireshark’s primary sponsor.
I’m excited for a couple of reasons. First, I get to work with Sysdig’s founder, Loris Degioanni. We’ve been friends for a long time, and it’s difficult to summarize the impact he’s had on Wireshark. We first met in the early days of the project, back when it was still called Ethereal. At the time he was busy developing the WinPcap packet capture library, which was a natural fit for Ethereal and let us include Windows users in our community. This was a pivotal milestone for the project and it helped us grow into what it is today.
This isn’t the first time he’s asked me to join a company he founded. In 2006, my family and I moved halfway across the U.S. where I joined him at CACE Technologies and he welcomed us to our new town. We renamed the project to Wireshark and proceeded to build a line of products that complemented it. This was another pivotal time for Wireshark. We started hosting SharkFest, our developer and user conference. It allows the community to meet and share ideas in person, and it’s hard to overstate its importance to the project. I was (finally!) able to work on Wireshark full time, and with the help of our wonderful community, it grew to be the world’s most popular network protocol analyzer.
I’m also excited because Wireshark has a great sponsor in Sysdig. I was delighted to find that he’s built a wonderful company culture here. Everyone I’ve met is bright and creative, and open source is a huge part of the company and its culture. They sponsor the Sysdig system visibility tool (which Loris created) and the Falco runtime security tool. As part of Sysdig I’ll be applying what I’ve learned about low-level visibility to cloud environments.
Sysdig’s sponsorship will ensure that Wireshark and its community continues to grow. Wireshark has a wonderful community of users, developers, and educators and the work they do is important. Sysdig is cognizant of that and committed to supporting that community. They will continue to host SharkFest and support the community that builds and delivers the world’s best protocol analyzer.
Finally, I’d like to thank Riverbed for being such a great sponsor for so many years prior to this. Wireshark has been fortunate over its lifetime to have sponsors dedicated to supporting its community, and Riverbed deserves recognition for being a huge part of that.
Dedication and Disagreements
As I’ve mentioned in many of my talks about the Wireshark project, our primary goal is to help as many people as possible understand their networks as much as possible. We’ve been very fortunate over the years in this regard. Many people are passionate about this goal and have dedicated themselves to help to work toward it.
Although a group of people might agree about a particular goal, they can sometimes disagree about how to get there. When you add in personal dedication and investment, the disagreement can take on a life of its own. This happened to us recently.
Years ago when I worked at CACE Technologies we created the Wireshark Foundation1. A couple of years later, Laura Chappell came up with the idea for Wireshark University and the WCNA certification program. She worked out an agreement with CACE’s CEO to license use of Wireshark’s trademarks which they subsequently signed.
Shortly after that, Riverbed acquired CACE, along with the Wireshark Foundation. Like CACE, Riverbed has been both supportive of the project and hands-off. They pay my salary, fund SharkFest and our infrastructure, and have done so since the acquisition. We always strive to do more, and last fall it was suggested that we might be able to bring in extra money to fund more initiatives which would improve Wireshark and benefit the community.
One of the ideas for extra revenue involved restructuring Wireshark University in the hopes of including more educators. We presented the plan to Laura, and it didn’t go well. Our relationship deteriorated to the extent that Laura now maintains that Riverbed has taken over Wireshark. I love and respect her and will be forever grateful for what she’s done for the Wireshark community, but I strongly disagree with this viewpoint.
Riverbed has and continues to be very hands-off with Wireshark and is dedicated to our independence. They don’t dictate our roadmap or otherwise try to push us in a particular direction2. In my keynote3 at SharkFest ’19 US, I talked about creating an independent entity for the Wireshark Foundation and our assets, and they’ve been supportive of the entire process.
Going Forward
Although we weren’t able to come to an agreement on Wireshark University, there was never any question that Laura is welcome to keep using the Wireshark trademark to describe the purpose of her training courses, books, and the WCNA certification program. I would personally prefer that she continue to use the name “Wireshark Certified Network Analyst” — we would just need to have a proper agreement in place. If any of this wasn’t made clear to her over the past few months then that’s on me.
Please don’t let this dissuade you from buying Laura’s books, attending her classes, or going through the WCNA program. She’s a great educator and we share her passion for helping people understand their networks.
Also please be assured that Wireshark is and will always remain Free and Open Source Software. I am forever grateful to our global group of enthusiastic developers who continue to evolve the project. However, stuff costs money, and some of the initiatives we’ve discussed include (but aren’t limited to) hiring support staff. In order to serve the user and developer community and fund the project we must explore options such as charging for non-exclusive use of the Wireshark University trademark.
[1] I don’t recall the precise reason, but it was most likely to reduce CACE’s exposure in the event that I left the picture. They were betting the farm on Wireshark. It should be noted that my daughter and I were on Southwest flight 812, so this wasn’t an unreasonable concern.
[2] Aside from the occasional bug report from one of my co-workers. 🙂
[3] See the “Sustainability” the keynote at https://sharkfestus.wireshark.org/sf19, about 36:15 in.
Wireshark Is Now Twenty
Twenty years ago today I announced Ethereal 0.2.0, which marks the first public release of what is now Wireshark. The release was an attempt at two things: to create an interactive protocol analyzer for Linux and Solaris so that I could do my job better, and to give back to the open source community. As it turns out the second goal had a huge effect on the first one. After the initial release developer and user communities quickly formed. Different people had different goals such as support for other platforms and protocols, troubleshooting in specific environments, education, product development, network forensics, and so on. After a while things settled down to a single goal:
To help as many people as possible understand their networks as much as possible.
As goals go that’s pretty broad and implies a lot of work. Open source project hosting services didn’t exist in 1998 so in the olden days we pretty much ate sand. For example, I made thirty releases in the first year. Twenty of them were first two months. That’s because I was our revision control system1. Contributors would send me patches, I’d apply them to my source tree and then make a release. Everyone would then sync their source directories with the new release. Fortunately we stopped doing that in short order. Other parts of the project followed similar paths. The first Windows packages were ZIP files with no capture driver. Our first web server was a 40 MHz SPARCstation IPX with 64 MB of RAM. We inflicted X11 on our macOS users far longer than we should have.
The project grew from those humble beginnings to what is today – the world’s most popular network protocol analyzer. The goal is still there, and many people and organizations are helping us achieve it. We have a wonderful sponsor in Riverbed, which pays my salary, provides our infrastructure, and sponsors SharkFest, our developer and user conference2. It’s managed by Janice Spampinato, who does a spectacular job of making sure our community can share its knowledge face to face in a welcoming environment. Speaking of SharkFest, we’re having three of them this year! Laura Chappell does a correspondingly spectacular job with Wireshark University, educating users throughout the year. Our user and developer community is second to none in its expertise, knowledge, and willingness to help.
I could not be more proud of what we’ve accomplished and look forward to the challenges and opportunities. On behalf of the Wireshark development team, thank you for your support.
1. Never, ever do this. If you want to start a project, just commit your code to GitLab. Or GitHub. Or BitBucket. Or anything else that doesn’t involve manual patching.
2. If your career involves looking at packets you should maybe show up once in a while.
The Cloudflare Incident And Its Impact On Wireshark.org
Cloudflare recently announced a security incident that potentially impacts anyone who visited various wireshark.org and winpcap.org sites for the past six months.
What happened?
Cloudflare is a popular service that provides content delivery, DDoS protection and DNS services for web sites.
A software bug Cloudflare’s servers leaked potentially sensitive information. Some of that information ended up in caches all over the Internet. At Google, Microsoft, your ISP, your company’s or university’s proxy servers, and elsewhere. Due to the randomness and distributed nature of the bug, it’s difficult to know what the full impact is. Cloudflare provides the following estimate:
“The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that’s about 0.00003% of requests).”
The bug was introduced on September 22, 2016 and fixed on February 18th, 2017.
The Google Project Zero bug describing the issue in detail can be found at https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
Cloudflare’s incident report can be found at https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/
The initial Hacker News discussion can be found at https://news.ycombinator.com/item?id=13718752
Was Wireshark affected?
The following wireshark.org and winpcap.org sites were behind Cloudflare proxies during the period in question:
- ask.wirehsark.org
- blog.wireshark.org
- bugs.wireshark.org
- sharkfest.wireshark.org
- sharkfesteurope.wireshark.org
- wiki.wireshark.org
- www.wireshark.org
- www.winpcap.org
Wireshark’s download servers (*.dl.wireshark.org), buildbot.wireshark.org and code.wireshark.org were not behind Cloudflare.
I browsed to a one of the sites listed above between September 22nd, 2016 and February 18th, 2017. Am I affected?
The chances are slim, but those chances are not zero.
Most of the content that we serve is “static” and “public.” That is, it’s the same for everyone and doesn’t contain any sensitive information. The risk exposed by Cloudflare is from dynamic content that contains sensitive information such as the login page on ask, bugs, wiki, etc. Our web sites get frequent requests for static content, but dynamic requests are relatively infrequent.
In a world where everyone has infinite free time I would have no qualms about recommending that everyone with a wireshark.org account change his or her passwords. However, this is the real world and your time is valuable. If you logged in to one of our sites and used a unique password it might not be worth your time to change it. On the other hand, if your professional reputation depends on your ask.wireshark.org score you probably should. If you have any sort of administrative access you definitely should. Most of our users fall into the first category.
If you’re wondering why it looks like I’m downplaying the importance of changing your wireshark.org passwords, see the next question.
I used a web browser, smart phone, or an internet-connected wearable doohickey between September 22nd, 2016 and February 18th, 2017. Am I affected?
I honestly don’t know. The chances are almost certainly not zero.
Cloudflare is a very popular service. At the time of this writing an unofficial list of affected sites stands at more than four million entries and counting. It includes many of the world’s most popular web sites.
If you’re going to spend time changing passwords, doing so for sites that deal with finance, email, DNA testing, dating, and other parts of your personal life probably ranks higher than that for, say, the Wireshark wiki.
Isn’t a vague answer like “the chances are slim but not zero” a frustratingly craptastic one compared to a definitive “yes” or “no”?
Yes, but it’s also the honest and correct one.
Update: March 2, 2017
Yesterday Cloudflare posted an update on the issue at https://blog.cloudflare.com/quantifying-the-impact-of-cloudbleed/. In it they posted the following leak estimates:
Requests per Month Anticipated Leaks
------------------ -----------------
200B – 300B 22,356 – 33,534
100B – 200B 11,427 – 22,356
50B – 100B 5,962 – 11,427
10B – 50B 1,118 – 5,926
1B – 10B 112 – 1,118
500M – 1B 56 – 112
250M – 500M 25 – 56
100M – 250M 11 – 25
50M – 100M 6 – 11
10M – 50M 1 – 6
< 10M < 1The affected wireshark.org web sites get just over 10M requests per month combined. Private traffic is substantially less than that.
Getting Ready for SharkFest ’16
The week leading up to SharkFest is always a busy and hectic time around here, but it’s also exciting. I can’t wait to see everyone, and the talks and labs this year promise to continue our tradition of imparting protocol analysis knowledge and insight.
If you’re sill unsure about attending, perhaps this list of reasons for attending that Laura Chappell recently posted will sway you:
1. Gerald Combs and the Wireshark Developers
Gerald Combs, the creator of Wireshark (formerly Ethereal), and many of the core developers will be there actually working on the code in the Developer’s Den. They will be presenting many of the sessions, joining in on the social events (they are a fun group!) and sharing tips and techniques to improve your analysis process.
2. Wireshark Experts as Presenters and Varied Content Levels
There is no dispute that the presenters at SharkFest are the world-authorities on troubleshooting, security analysis, and network optimization. These are the folks who live in the world at packet-level and can spot a rogue packet at 50 paces! Through a variety of introductory through advanced lectures and hands-on labs, these presenters will show you some hot Wireshark techniques to speed up your time to resolution.
3. Focus on Wireshark 2
It’s time to move up to Wireshark 2. All the presentations and labs at SharkFest ’16 will be focused around the new version of Wireshark. From new features to new techniques, accelerate your migration to Wireshark 2 by getting an inside look at how the experts work their magic.
4. The Reef at SharkFest
I will be hosting The Reef again at SharkFest. The Reef will host hands-on lab exercises, numerous Wireshark University Certified Instructors, Wireshark experts, and Wireshark Developers. Come in and try your hand at the labs and pick up the SharkFest Packet Challenge. This is a great opportunity to mingle amongst Wireshark gurus and hone your troubleshooting and network forensics skills.
5. Hands-On Labs
Get your hands dirty in one of the lab sessions at SharkFest. This year we have added a 100-seat hands-on classroom to SharkFest. This is in addition to the 300+ seater Hahn auditorium. We will also have numerous lab exercises hosted in the Reef and folks to help out on the more challenging labs.
6. Social Events and Peer Networking
The SharkFest team has put together a Welcome Dinner, Vendor Night Party, “Sake’s Surprise” Dinner, and Closing Reception to give you plenty of time to network with other analysts. The casual atmosphere of the Grand Hall lunch area and the Reef offer plenty of opportunities to meet and mingle with other attendees and the developers.
7. Packet Challenge
Again, you will have the chance to test your skills in the SharkFest Packet Challenge. Pick up the Challenge Worksheet in the Reef and grab the USB stick filled with trace files. Turn in your answers in the Reef by Wednesday evening and join us for the Packet Challenge Awards Ceremony in the closing keynote timeslot.
8. Analysis-Focused Vendors
Vendor night is a highlight of the event. As the band plays and the food sizzles on the grill, visit the vendors who sponsor SharkFest. Each vendor is focused on network analysis, troubleshooting, security, optimization and other related topics. These are the folks we all work with to build the most effective analysis environments possible.
9. Computer History Museum and the Revolution
Considered one of the world’s best collection of historical objects relating to the computer industry, the Computer History Museum is a must-see destination for folks in the tech industry! During SharkFest, you will have time to visit the Revolution exhibit to see history in the making. This is our second year at the Computer History Museum – it’s an amazing venue.
10. Sake’s Surprise
I can’t wait to give you more details on this one. Right now, the surprise is in development. It should really be a highlight at SharkFest ’16. As soon as I’m allowed to spill the beans, I will!
11. Troubleshooting with Wireshark Pre-Conference Class
As an extra here, I will be teaching a 3-day class just before SharkFest. The focus is troubleshooting, troubleshooting, troubleshooting! Get the bundle pricing for SharkFest and the 3-day class at https://sharkfest.wireshark.org/registration16.html.
If you can’t attend SharkFest U.S., these reasons also apply to SharkFest Europe. If you are attending either conference, I’ll see you there!
Let me tell you about Wireshark 2.0
We’re getting ready to release Wireshark 2.0, which includes a major user interface update. As a comparison, here’s a picture of Wireshark 1.12.8, which is the current stable release:
Here’s a picture of Wireshark 2.0.0rc2, which is the current development release:
See? Totally different.
Actually, quite a few things have changed. The user interface has been completely rewritten using a different interface library (Qt). It has been streamlined so that you can work faster and it should have a better look and feel on every platform. The screenshots above are similar because we’ve also tried to ensure that the new UI is familiar to current users. The features you’re used to are still there and in the same place (or at least nearby). They should work much more smoothly, however.
I can’t hope to cover all of the changes in Wireshark 2.0 in one blog post, but here are a few highlights:
Capture options. Capture options have been simplified and consolidated. In 1.12 they are spread out in many places across several windows. In 2.0 they are in two places: the Capture Options dialog (Capture→Options or the “gear” icon in the toolbar) and the Manage Interfaces dialog, which you can open by pressing “Manage Interfaces” in the Capture Options dialog.
Streamlined preferences. Preferences windows usually aren’t something to get excited about and this is no exception, but it’s important to note that in the process of removing clutter some preferences have been removed from the main window. They’re still available in the “Advanced” preference section which lists every available preference item.
Translations. Thanks to the hard work of many contributors the new interface supports multiple languages. You can now select between Chinese, English, French, German, Italian, Japanese, and Polish in the “Appearance” preferences section. Many more translations are underway. You can see the status the translation efforts and help out with the effort at https://www.transifex.com/wireshark/wireshark/.
Related packets. As you scroll through the packet list you might notice little symbols pop up along its left edge. For example, you might see left and right arrows for DNS requests and Replies, or a check mark to denote an ACKed TCP packet. These are related packets. This exposes some plumbing we’ve had in place for a long time, but it’s now shown in the main window instead of buried deep in the packet detail tree.
Intelligent scrollbar. As you scroll through the packet list you might notice that the scroll bar itself looks odd. It now features a map of nearby packets, similar to the “minimap” available in many modern text editors. The number of packets shown in the map is the same as the number of physical vertical pixels in your scrollbar. The more pixels you have, the more packets you can see. In other words, if you use Wireshark regularly you now have a legitimate business case for a retina display.
Statistics dialogs. The dialogs under the Statistics and Telephony menus have seen many improvements. The backend code has been consolidated so that most of Wireshark’s statistics now share common internal logic. This in turn let us create common UI code with many workflow improvements and a much more consistent interface.
I/O Graph dialog. You can now graph as many items as you like and save graphs as PDF, PNG, JPEG, and BMP. Graph settings stay with your profile so you can customize them for multiple environments.
Follow Stream dialog. You can now switch between streams and search for text.
General dialogs. Many dialogs now have context-aware hints. For example the I/O Graph and Follow Stream dialogs will tell you which packet corresponds to the graph or stream data under your cursor. Most of them will stay open after you close a capture file so that you can compare statistics or graphs between captures.
If you want to see a live demonstration of the new UI, Laura Chappell and I are presenting a webinar next week on the 12th at 10:00 AM PST. You can register at http://bit.ly/wireshark2.
The final 2.0.0 release should be available in a couple of weeks. I’m excited about the new UI and about the opportunities that it provides for new features and further improvements.
Cool New Stuff
Hello everybody, we’ve got a handful of miscellaneous announcements for you today. They all just happened to occur within a handful of days, so it made more sense to lump them all into one post.
- Development version 1.99.1 was released, another milestone on the road to 2.0 and our shiny new Qt interface. You can read the full announcement with release notes here, and download it from the “Development Release” section of here!
- Tweet tweet! That’s right, we have an official twitter handle now for announcements and the like. It is shared by several of the core developers, but mostly run by our fearless leader Gerald. Follow us @WiresharkNews to find out more!
- Thanks to the hard work of our Debian maintainer Bálint, we now have an Ubuntu PPA (Personal Package Archive) containing the latest stable Wireshark releases pre-built for all the supported Ubuntu releases. If you’ve ever wanted the latest and greatest Wireshark on an older version of Ubuntu, now’s your chance, so get it here.
- Last but not least (although this one’s older – it actually launched way back in June), our repository now has an official github mirror. Please note that this is a convenience only; pull requests and issues will still go through our existing Gerrit and Bugzilla sites. The github mirror is very much *just* a mirror, but it is handy to have none-the-less.
That’s all we’ve got for you today, hopefully one or more of the above items caught your eye.
Wireshark 1.12 Officially Released!
We are proud to announce the release of Wireshark 1.12.0! This is a fairly significant release for us, as we expect it to be the very last release using the GTK toolkit in the default interface (see this post for our plans to replace it).
Wireshark 1.12 contains a substantial number of fixes and new features, representing just over a year of development effort. Check out the release notes for full information on what’s new and improved, and download it now!
If you have any issues with the new version, please file a report in our bug tracker.
To Infinity and Beyond! Capturing Forever with Tshark
Over the last couple of years that I’ve been involved with Wireshark, one issue has reared its head a significant number of times in a surprisingly varied number of ways. These range from “Capturing with tshark uses more and more memory!” to “I set tshark to capture in the background, and it keeps crashing!” to “How do I set up tshark to capture forever?”
Historically we’ve had no good answer to these complaints – Wireshark and tshark both only do what is called stateful dissection. This means that they store what they’ve seen in memory and use that information to provide additional details about future packets, for example by matching requests with responses. While this provides substantial benefits — reassembly of protocols over TCP being probably the most obvious — it means that as the amount of traffic increases, so does the amount of memory needed to store all of that state. It also means that there’s no way for tshark to run forever unless you’ve got infinite memory (what’s your secret!?) or no traffic at all.
All of that has just changed. Wireshark and tshark have long had a feature that lets you rotate your packet capture across multiple files, preventing any one file from getting too large; to do this, check out the “-b” flag to tshark. This was handy for systems limited in disk space, but did nothing for the ever-growing memory usage. A few days ago, however, I landed a change in tshark’s master branch that makes it discard its internal state every time the capture rotates to a new file. This has one huge benefit: you can now capture (theoretically) forever with tshark by using the “-b” flag!
Like any experimental change however, it does currently have a number of limitations:
- State is lost when we switch to a new file, so if two fragments of the same message get split across that file boundary, they will not be reassembled. This is effectively unavoidable – while we considered discarding only very old state, this turns out to be extremely difficult with our current architecture. However, the result is that the dissection you get when capturing with “-b” should actually be closer now to the dissection you get when opening the individual files after the fact.
- Discarding state can be a surprisingly expensive operation, so captures using this feature in high-traffic environments may see their dissection fall behind when switching to a new file. If you see this, please file a bug report with as much detail as you can provide, and we will try to smooth out the rough edges.
- Memory usage might still grow a very small amount due to previously-hidden memory leaks now being much more obvious. Again, if you see anything problematic, please file a bug report.
- This feature is limited to tshark only, it is not available in the graphical Wireshark interface. The graphical interface has to permit scrolling backwards to look at previously dissected packets, so it can’t discard anything until the entire capture is closed. (Edit: This isn’t strictly true – now that I’ve actually checked my assumptions, it should be possible to make the GUI behave the same way. It will take some additional work though.)
- This feature is limited to the master branch only, it will not be in the upcoming 1.12 release. Given the substantial nature of the change, it was decided that it needed a chance to cook before being released as a “stable” feature. It is, however, present in the 1.99 automated development builds as of this morning.
Please test it out and let us know what you think. Happy capturing!
Detecting Heartbleed Traffic
The big news in the tech industry this week is The Heartbleed Bug, a vulnerability that affects a large portion of secure web sites on the Internet. I updated the Wireshark and WinPcap web sites on Monday (along with reissuing and revoking certificates) shortly after OS patches were released.
Our web sites are protected going forward, but what about the past? We have a Shark appliance in our environment but that leads to a challenge. We had about 350 GB of HTTPS on our network on Monday alone. This is just slightly too large to load into Wireshark.
Fortunately one of my coworkers (P.J. Malloy) came up with a BPF filter that matches Heartbleed traffic:
Applying this filter directly on the Shark appliance gave me a much smaller number of packets which I could easily analyze in Wireshark. So far I haven’t found anything suspicious.