Verisign
Donald Miller
Verisign's possible abuse of their control of .com and .net. In a
posting in grc.privacy, it was stated that some ISPs have made changes
to lessen their dependency on Verisign. What are the thoughts of my ISP
on this issue? If you can't say anything in public, I understand.
Thanks, Don
--
___________________________________
Protected by stuff
Larry__Weiss
> ... In a posting in grc.privacy, it was stated that some ISPs have
> made changes to lessen their dependency on Verisign.
>
What sort of changes?
Donald Miller
http://news.com.com/2100-1038_3-5092133.html?tag=nefd_top
Larry__Weiss wrote:
What sort of changes?
Gordon Burditt
>> made changes to lessen their dependency on Verisign.
>>
>
>What sort of changes?
If you own a domain, you can transfer your registration from Verisign
to another registrar. You might save money in the process, too.
If you administer an ISP, local LAN, or even a home network, you
can install the latest version of the BIND nameserver and use the
newly-added features to ignore Verisign's *.com and *.net wildcard
records. (Most home users use their ISP's nameservers, and setting
up your own is a bit complicated.)
Some problems that Verisign's SPAM finder, er, site finder thingy
has caused:
- Sites that check if the return address is valid on mail as a SPAM
filter let in a lot of spam, since random made-up return addresses
now appear valid.
- The broken-link detector I use on my web pages thinks links that
point to nonexistent hosts are valid and doesn't alert me to the
problem.
- The massive amount of mail traffic (usually bounced SPAM with fake
return addresses) to Verisign's mail server can cause slowdowns in
mail delivery even though Verisign's "mail server" is a dummy that
just rejects everything. Even worse slowdowns are possible if it
goes down.
The following are suggestions that an ISP shouldn't follow because
of the high potential for annoying customers but an organization
or individual user might if they are annoyed enough:
You can firewall all of Verisign's IP addresses. This, however,
tends to make web pages take a long time to time out rather than
displaying Verisign crap immediately.
You can set up your DNS server to answer for Verisign's own domains
and authoritatively claim there's nothing in it, making their domain
effectively disappear for hosts using your DNS server. (It is possible
to use the Windows 'hosts' file for a similar purpose to get rid
of, say, web sites containing ads and no content you consider useful
by pretending their IP address is, say, 127.0.0.1 (localhost)).
You can shoot yourself in the foot this way, though. You may lock
out more than what you intended if the host is a name server or
mail server.
You can set up your DNS server to deny access to queries from Verisign's
servers. This may have the effect of preventing them from sending you
mail. Move all your domain registrations before doing this, or you'll
be preventing the move from happening.
Gordon L. Burditt
Larry__Weiss
> >> ... In a posting in grc.privacy, it was stated that some ISPs have
> >> made changes to lessen their dependency on Verisign.
> >>
> >
> >What sort of changes?
>
> If you own a domain, you can transfer your registration from Verisign
> to another registrar. You might save money in the process, too.
>
> If you administer an ISP, local LAN, or even a home network, you
> can install the latest version of the BIND nameserver and use the
> newly-added features to ignore Verisign's *.com and *.net wildcard
> records. (Most home users use their ISP's nameservers, and setting
> up your own is a bit complicated.)
>
> Some problems that Verisign's SPAM finder, er, site finder thingy
> has caused:
>
http://en.wikipedia.org/wiki/VeriSign has some pretty good descriptions
of this issue and has some interesting links.
Jer
The following is a partial cite of an earlier post of mine on 9/19/03....
==================================================================
<quote>
I already know what I'm gonna do....
http://www.isc.org/products/BIND/delegation-only.html
By applying this patch to bind9 I'll stop the resolution of
non-existent domain names. The reason this is important is if someone
typos a URL containing a password...
for example:
http://www.BOGUS.com/login.cgi?username=me%20password=secret
Then Verisign would have a log entry on their webserver containing the
source IP address of an external proxy registered to me, the username
and password, plus if they wanted to they could steal cookies which
contain much more information, and not only Verisign but every network
in between could potentially log the URL and the password and any sent
cookies or certificates. After a period of time the receiving
networks of this misguided internal traffic could use the HTTP
requests they received to exploit my network. Perhaps you can dismiss
this as paranoia, but in reality anyone on the internet between
Verisign's wildcard "A" host and me can perform what is known as a
"man in the middle" attack by receiving traffic for the end host via
bogus arp or routing information insertion on a transit network
device, Verisign would have no idea this was going on as long as the
host in the middle passed traffic to the Verisign host after receiving it.
I would also advise all networks internally to discard traffic for
64.94.110.11/32 (example: on border routers add this line to your
Cisco router configuration "ip route 64.94.110.11 255.255.255.255
null 0" ) in order to prevent internal traffic from leaking to this
ratbastard host.
</quote>
==================================================================
--
jer email reply - I am not a 'ten' ICQ = 35253273
"All that we do is touched with ocean, yet we remain on the shore of
what we know." -- Richard Wilbur