HAQUE.NET > Evil VeriSign

..::: EVIL VERISIGN :::..

Note: I am just posting this rant. I am not responsible if anything in this rant rubs you the wrong way. This whole thing pisses me off. See what happens when you let one company control something?

I encourage everyone to call up their ISP and explain that you have typed in an non-existant domain name and been directed to VeriSign's SiteFinder service. Tell them that you have read the Terms Of Use linked at the bottom of their page and that you do not agree to their terms and thus forbidden from using their service. Demand that they do something and exclude your IP/account from getting redirected to SiteFinder. (You should also call VeriSign and tell them the same.)
-- BatmanPPC (Mohammad A. Haque)

Related links:
VeriSign's post to NANOG announcing SiteFinder

By: Jason Garman
September 15, 2003

Every so-called "computer geek" has no doubt had the pleasure of dealing with a user who is convinced that the entire Internet runs off of a central "Internet server". How many times have you heard "I can't get my email, the Internet server must be down!" (Okay, I'll avoid pointing out the sheepish look on the guy in the back who has uttered those words himself.) It's from this little piece of technical support lore that my friends and I have a running joke that I run the "Internet server" (for our group, of course) and every time it's unreachable for some reason or another, we tell each other, "the Internet server's down!"

So what am I trying to get to? Well, as of 20:00 EDT time on Monday, September 15, 2003, there is now an "Internet server". Its name is sitefinder.verisign.com, currently found at the IP address of 64.94.110.11. Every request for an Internet domain name that doesn't exist, has expired, or is simply misspelled, will be answered with this magical site. What does this mean? Why is this bad? In order to answer these questions we have to first take a step back and examine the structure upon which the Internet is built, the Domain Name Service (DNS). Those of you with a working knowledge of DNS can nap through the next few paragraphs; you'll be interested in what VeriSign has broken with their stroke of genius, which I'll cover in a bit.

The DNS is the world-wide phone book which maps the names you see in your web browser (for example www.mysite.com) to an IP address, a number that the computer can use to find the site. The DNS is a critical part of the Internet; without DNS, practically everything would stop flowing. E-mail would not reach its recipients, web browsing would grind to a halt, online commerce would cease. It is for that reason that the servers and databases that make up the DNS are distributed geographically. The DNS "root" servers -- the servers that represent the well known "top level" domains of com, net, org, and so forth are distributed across the world to avoid a single point of network or system failure. If one system fails, or if its network is cut off due to a power outage, network attack, or catastrophe, then there are a dozen other servers that can take over the load for the failed machine.

However, one critical point of failure remains. It's not a point of failure in the traditional, network or hardware sense, because as we've already discussed, the designers of DNS have already accounted for this. No, it's a much more thorny and difficult point of failure to resolve: it's the fact that one company "owns" the database for the two most used top-level domains on the Internet, .com and .net. VeriSign, Inc. acquired Network Solutions, the company that has the blessing of the United States Government to administer this very critical piece of network infrastructure. So while we have achieved a technological marvel by assembling a network spanning the globe, a network that can survive attacks, accidents, catastrophes from backhoes in Ohio to virulent software that infects hundreds of thousands of machines, we have failed to recognize the real point of failure in the Internet infrastructure: the single point of failure that has been placed directly into VeriSign's lap.

Now, back to what VeriSign's done. Before September 15, DNS lookups for unknown domain names would respond with a "domain not found" error. No doubt anyone who has used the Internet has received one of these. The advantage is that network operators, technical support, and users can easily recognize if a site does not exist. Now, VeriSign has implemented a so-called 'wildcard' record, which means that *every* DNS request for a domain that doesn't exist will be redirected to themselves.

What's wrong with VeriSign's actions? Let's take a look at the myriad of reasons from a technical and legal standpoint, and then we'll finish off with the moral and ethical concerns that I, personally, along with many other network operators, have about this change. Before we do that, however, let's start off with one very important point: the irresponsibility of making this change to the critical infrastructure of the Internet without the input of the thousands of network operators who, collectively, make the Internet work. VeriSign must realize that as the maintainer of the databases for the two most-used TLDs on the Internet, .com and .net, it has a great responsibility to the Internet as a whole and must put the health of the Internet before its own commercial interests.

As VeriSign has implemented this without prior notification or warning, there has been little time (about an hour and a half at the time of this writing) to fully examine the technical breakage that will occur as a direct result of this change. There are a few problems that are already evident, however. One is the operation of some anti-spam filtering software. Among the other protections that spam blocking software employs, one method to block spam is by blocking messages that appear to be sent from non-existent domain names. This feature magically stopped working tonight, as there is no way for a domain name lookup to fail. Next, there is VeriSign's handling of SMTP connections aimed at their wildcard host. According to an "Implementation" document posted to NANOG (the North American Network Operator's Group) list by a VeriSign employee, the SMTP listener on the sitefinder.VeriSign.com host should refuse all mail. To quote the document:

"The Site Finder response server runs a limited SMTP server that returns an SMTP 550 error response for any specified destination (i.e., any RCPT TO value). The error message includes explanatory text explaining that the message did not reach the intended recipient because the destination domain does not exist."

However, this does not seem to be the case, as tested at 22:30 hours EDT on September 15:

% telnet asijfoawiejawoef.com 25
Trying 64.94.110.11...
Connected to sitefinder-idn.verisign.com.
Escape character is '^]'.
220 snubby1-wceast Snubby Mail Rejector Daemon v1.3 ready
help
250 OK
mail from: <bljsoijwef@oijfoewijfoawief.com>
250 OK
rcpt to: <abuse@verisign.com>
550 User domain does not exist.
rcpt to: <postmaster@verisign.com>
250 OK
data
221 snubby1-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel

This response is dramatically different from what is called for in VeriSign's own Implementation documentation. Instead of returning a 550 error code for our example domain, the mail server continues with a positive, 250 OK response. The mail server gives up only after I attempt to send it the contents of the email message -- this is handled by most mail transfer agents as a transient error and will continue retrying for several days to send the message. This will cause problems for legitimate e-mail whose mail addresses have been mistyped by the sender. Perhaps even more disturbing is the fact that VeriSign, at its choosing, could easily decide to intercept such misdirected e-mails by not closing the SMTP connection after the "DATA" command. Already VeriSign has a record of the sender of any messages whose destination addresses have been misspelled through this change. I haven't even touched upon the professionalism of the "Snubby Mail Rejector" message and I am at a loss as to how the responses issued by this SMTP daemon provide explanatory text for an inexperienced Internet use that their message did not reach its intended recipient.

And that, in turn, provides a great segue into the legal aspects of VeriSign's new "service." Let me first emphasize that I am not a lawyer, and if I was, I wouldn't be handing out free legal advice anyway. To start the legal discussion, we can continue where we left off with the mail service provided by VeriSign's sitefinder wildcard DNS server. VeriSign themselves admits, in the same Implementation PDF file, that all accesses to the siteminder service are monitored and archived:

"2.4 Monitoring and Communication

VeriSign actively monitors all traffic associated with Site Finder, including DNS queries matching the wildcard entries in .com and .net and associated responses, and all traffic sent to the response server. This traffic is correlated and monitored in real time, 24 hours a day, seven days a week, by VeriSign's Network Operations Center.... Several hours of the complete traffic stream to the .com and .net name servers and the response server, as well as rolled up statistics, are stored for analysis."

It is not fully disclosed how this monitoring information will be used by VeriSign internally, or whether VeriSign will voluntarily provide this data to law enforcement upon request. The privacy implications here can be staggering, as mistyped URLs can contain sensitive information, including usernames and passwords. In fact, it can be demonstrated for a fact that VeriSign is not ignoring data after the domain name in a URL by typing in, for example:

http://www.boguswebsiteforVeriSign.com/myuserid=blah&mypassword=blah

The URL that we're redirected to is:

http://sitefinder.VeriSign.com/lpc?url=www.boguswebsiteforVeriSign.com/myuserid%3Dblah%26
mypassword%3Dblah&host=www.boguswebsiteforVeriSign.com

This demonstrates that the redirection script on VeriSign's servers is actively intercepting not only the domain name in the URL, but also any other data present in the URL.

A further worry for users is the privacy policy and terms of service posted on the Site Minder service. Not only does the simple act of mistyping a URL implicitly cause you, the end user, to accept VeriSign's Terms of Service and Privacy Policy without the chance to review and accept or decline either, but critical information as described above is not disclosed in either policy (as of this writing). The Privacy Policy clearly states:

"We do not collect any personal information from visitors to our Site Finder. Under no circumstances do we collect any personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, health, or sex life."

(Interesting that they specifically point out union membership and sex life... I haven't seen those singled out in any other privacy policy before...)

The point, of course, is that at no point in this Privacy Policy does VeriSign disclose the active monitoring and archival of the site's usage. The Privacy Policy goes on to say:

"We assure you that the information we gather from you about your visit is in aggregate form and solely for the purposes of operating and improving the performance of our Site Finder."

To the contrary, there is no doubt in my mind that individually identifying information will be collected as part of an active monitoring and archival system, once again, as disclosed by VeriSign themselves in the Implementation document.

Even after a thousand words or so, I haven't even begun to discuss the abuse of VeriSign's monopoly power to the exclusion of the hundreds of other accredited domain name registrars. I hope, however, that this quick document has at least begun to examine the latest Pandora's Box that VeriSign has foisted upon the Internet community. I leave you with one question, put best by the subject of the ongoing thread at NANOG on this subject: "What *are* they smoking?"