![[SJF Logo]](../../images/sjflogo.gif)
Every so often in the BroadbandReports security forum there is a posting asking why the local system is trying to connect to crl.verisign.net, and it's an entirely reasonable question. When your system starts making an outbound call for a reason you don't know, it means you're paying attention if you ask. Good so far.
It turns out this is a Certificate Revocation List service, which - like the name suggests - presents a list of SSL security certificates that have been revoked for whatever reason (expired, stolen, no longer used, etc.). Any google search can show you what a CRL is, but that's not the point. It's basically innocuous.
The problem is that the folks at Verisign have done everything they could think of to make this innocuous activity look suspicious. Users only find out about this when they trip across it (firewall tells them, they see a netstat connection), so it seems natural to visit the web page in question and see what's what. This is what they see:
It's a file list with names that suggest nothing. Those taking the time to dig a little find a README.txt file there: could this explain it? Not really.![[crl.verisign.net file listing]](../../blogfiles/verisign-idiots.gif)
said by README.txt:This makes it worse: unless you're internet savvy (such as Jeremy, who figured it out right away when I pinged him), it just looks totally fishy. No wonder people freak out.
VeriSign Certificate Revocation List Usage AgreementYOU MUST READ THIS VERISIGN CERTIFICATE REVOCATION LIST USAGE AGREEMENT BEFORE DOWNLOADING, ACCESSING, OR USING ANY CERTIFICATE REVOCATION LIST ("CRL") IN THE DIRECTORY WHERE THIS DOCUMENT RESIDES; ANY CRL OTHERWISE OBTAINED, DIRECTLY OR INDIRECTLY, FROM VERISIGN, INC. ("VERISIGN"); OR ANY INFORMATION CONTAINED IN ANY SUCH CRL. IF YOU DO NOT AGREE TO THE TERMS OF THIS VERISIGN CERTIFICATE REVOCATION LIST USAGE AGREEMENT, YOU ARE NOT AUTHORIZED TO DOWNLOAD, ACCESS, OR USE ANY VERISIGN CRL OR INFORMATION IN SUCH CRL.
blah blah blah
If any website is asking for an "index.html" in its root directory, this one is. Providing a "If you're wondering why you got here..." page would go a long way to educating users about activity on their own computers, showcase the services that Verisign offers, and - more broadly - easing the fears of those who suspect conspiracies everywhere.
Big companies (Microsoft, Verisign, many others) get plenty of bad press for behavior that is arguably bad, so when it's not actually bad behavior they ought to go the extra miles to make them go away.
How hard could it be?
---
Update: It seems that there has been a rash of recent (Jan 2004) activity on the CRL front, and it's caused by expiration of many certificates. This has apparently caused havoc with Norton Antivirus and some other products, and it's discussed here at BroadBand Reports
It seems that Netgear routers have been shipping with a hardcoded IP address of an NTP (Network Time Protocol) server at the University of Wisconsin, and they got hit with hundreds of thousands of packets per second of traffic from Netgear customers all over the world. How unbelievably lame that Netgear didn't think about "scaling issues". Wow.
With the exploit of yet another Microsoft bug (MSBLAST), it's prompted me to propose a solution that would go a long way in containing these problems: I've never figured out why Microsoft hasn't implemented it.
The NETBIOS, CIFS and RPC core engines should have a "Local connections only" flag somewhere, and reject all connections and probes from IP addresses not directly connected to a local interface (as determined by IP address and netmask). This flag would be TRUE by default, and would require the user to override in the TCP/IP properties or perhaps picked up by DHCP.
This approach would allow most of the networking services to be enabled by default, but they would not be usable by anybody outside the local network. Most home users would be functional and mostly secure even if they had no firewall: no "security versus functionality" tradeoff for most.
This wouldn't be a complete fix - cable modem users have "neighbors" on the same network - but would not allow The Great Unwashed to be exploited by script kiddies and worms from all over the world.
Can anybody think of a reason why this wouldn't work?
Ugh: the SOBIG.F virus is running around *everywhere*, so I've created some header_check rules to get Postfix to reject this mail before it even enters the network. I certainly have enough sense not to open a PIF file, but not everybody I perform relay for do. Sigh.
Tech Tip: Rejecting SOBIG.F Virus Mails from Postfix
With the whole MSBlast worm running around ready to attack windowsupdate.com, Microsoft has simply removed this entry from its DNS servers (there is no site with that name): this will cut the DoS attack at the knees.
But they could have a lot of fun with this: update their DNS to point windowsupdate.com to the webserver of somebody they don't like, such as www.aol.com, www.usdoj.gov or even www.unix-girl.com.
I'm sure it crossed their minds :-)
Well I have just upgraded my old Philips Tivo unit: I doubled the RAM and added the TurboNET card (both from 9th Tee Enterprises).
The RAM was tricky: I had to solder two 50-pin surface-mount RAM chips, but I've been soldering for 30 years so it was straightforward enough. Now I have 32 megabytes of RAM: it probably doesn't make things go any faster yet, but I'll next be updating the operating system to include a telnet daemon, a web server (for setting up recording of programs remotely), and onscreen caller-ID.
Even without the extra software, my Tivo now does its channel-guide upgrades over the network. It gets an IP address via DHCP over my network, so this makes it run right along.
Big thumbs up to Tivo for integrating the TurboNET drivers into the software and making the "update over the net" option available. Clearly this benefits them too (no need to pay for local POP service), but it's just a cool deal.
Also big thanks to Steve Gardiner for being my Tivo consultant.