As you may know, Chappell University has a trace file library on an FTP server (accessed via https://www.chappell-university.com/traces). A couple of days ago, I was going to take a look at the library when something strange happened... Nothing! Absolutely nothing happened.
<Insert snarky caption about how I use Chrome because I love Google™ and hate Privacy™.>
I stared at the new tab page in Chrome with ftp://www.wiresharktraces.com in the URL bar and the page stared back. Nothing happened.
I clicked the URL bar and pressed enter again. Nothing.
I hit refresh. Nothing.
Wireshark time!
Sniffing for Clues
The complete lack of activity is puzzling. No error message? No feedback? Is Chrome mad at me?
I flushed my browser cache and DNS cache and tried again - this time capturing my traffic.
To start off, I looked for the DNS request that my browser would have sent out for the trace library (dns contains "wireshark").
The Laura Chappell stans among you may be able to tell that this article isn't hers just from the absence of the torn-paper image effect... Or from my artistic flare.
Nothing. No DNS packets containing "wireshark" as I'd expect when trying to get to wiresharktraces.com. Though this seems like an obvious starting point to investigate, I wasn't so sure because I've been playing around with encrypted DNS lately. Maybe I had forgotten to turn something off and now my DNS was actually hidden in an HTTPS packet somewhere.
Google has been experimenting with DNS-over-HTTPS for a while and lets you choose to enable it in Chrome. I expect this to be Chrome's default in the future but that's a rant for another time. If my browser was encrypting my DNS traffic, then the absence of DNS seen above could mean nothing.
To figure out if my browser was encrypting DNS, I started another capture and went to a site in Chrome to see if I could see other DNS traffic generated by my browser. Sure enough, there it was.
An excellent site that lives up to its name.
So DNS encryption isn't the cause of my missing DNS queries. That doesn't rule out my browser as the cause of this issue. To do that, I need to compare it to another method. Let's head to the command line.
I retried getting to the FTP site at the command line and saw something even more incredible than nothing... SOMETHING! Very exciting.
Hacker voice: "I'm in... "
I was able to access the FTP server!
Sure enough, I can see the associated DNS traffic in Wireshark.
Two beautiful queries and two beautiful responses.
So it is Chrome! After some searching, I am able to confirm that Chrome no longer supports FTP URLs. As of Chrome 88, FTP support can be enabled through Chrome's flags settings page but there will not be FTP support by default.
In Chrome, find the setting here: chrome://flags/#enable-ftp
Goodbye old friend.
FTP is on its way out as far as browser support is concerned. Firefox and Safari don't support FTP URLs anymore either.
So there it is. If you want to access the Chappell University trace file library, you will have to enable FTP support in your browser. Or you could just go to the command line, I guess. :)
Note from Laura: I have placed my trace file repository on a Google drive now - no need to use FTP to access the files. I think this is a good change - although it is irritating folks who connected to FTP sites on a regular basis. This article shows how a quick trace file capture can point to the issue (I can't even tell you how many "your trace file site is broken" emails came in after this Chrome update). Always take the trace file. The packets never lie. (Oh... and I didn't realize I use that "torn edge" look on so many images - guess that's my "tell" - just like my ... drift-offs sometimes at the end of a sentence.)