Security → More on VeriSign

It was down for a bit, yesterday I think it was.

said by hpguru:

---

This unfortunately cannot be blocked by hosts.

---

i just tried with and without the hosts patch on the first page of this thread and it blocks it for me.

said by JoshNJ:

---

i just tried with and without the hosts patch on the first page of this thread and it blocks it for me.

---

It is only blocking the 2nd connection to Verisigns servers. It won't block the first connection unless the misspelled hostname is in your hosts file.

Here is a log (taken from Proxomitron) of the 2 connections I described above.

*** Log Reset ***

+++GET 162+++
GET / HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0((snip))
Host: www.verisignreallysucks.com
Connection: keep-alive

+++RESP 162+++
HTTP/1.1 302 Found
Date: Fri, 19 Sep 2003 04:03:35 GMT
Server: Apache
Location: »sitefinder.verisign.com/ ··· ucks.com
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
+++CLOSE 162+++

+++GET 163+++
GET /lpc?url=www.verisignreallysucks.com&host=www.verisignreallysucks.com HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0((snip))
Host: sitefinder.verisign.com
Connection: keep-alive

+++RESP 163+++
HTTP/1.1 200 Okay
Content-type: image/gif
+++CLOSE 163+++

In this log response 162 had to come from somewhere right? It didn't come from www.verisignreallysucks.com because the domain doesn't exist (not yet anyway), but do a lookup and you'll find the IP addy assigned to it also resolves to sitefinder-idn.verisign.com and so that is the source of response 162. sitefinder-idn.verisign.com responds with a 302 Found (a redirect) to sitefinder.verisign.com. This is where the hosts file kicks in, too late I might add. Response 163 is eDexter, a tiny http server bound to localhost:80 that speeds up hosts blocking by giving your browser a response instead of waiting to timeout.

So to reiterate, hosts blocking will not block the first connection. You'll have to block it at the firewall.

I'm finding the same thing since sitefinder-idn is being addressed by its ip address, and not its rDNS name. So having both addresses blocked by your firewall seems to the only real way to prevent it, unless your isp takes care of the problem, but I'm still waiting for my isp to do that.

I'm still finding communications out to the 64. address in my logs even with both sites are in my hosts file, which again goes along with its being contacted by the ip address.
Blocked Outgoing 18/Sep/2003 21:16:50 Block sitefinder-idn.verisign.com TCP localhost 1968 sitefinder-idn.verisign.com [64.94.110.11] 80 (Edited)MozillaFirebird.exe

Exactly. The Hosts file WILL work IF you enter every mis-spelled name on to your list. Otherwise, the Hosts file will play no role.

I realize that it may appear to work, but it makes no sense. ONCE the request goes out to the DNS server, the Hosts file is NOT queried again! The DNS server supplied the numerical IP address (64.94.110.11), so there is no reason for your computer to look AGAIN at the Hosts file for another one...

>> I realize that it may appear to work, but it makes no sense...

Edit: Ah, nevermind... I see you all are talking about first versus second connection to the Verisign site. Yes, I've seen the first connection, but for me all I was interested in was IE going to an error page, not the Site Finder site. (So, appearing to work is good enough for me at this point.)
[text was edited by author 2003-09-19 17:26:37]

said by R2:

---

I realize that it may appear to work, but it makes no sense. ONCE the request goes out to the DNS server, the Hosts file is NOT queried again.

---

Actually, so far, it appears to work every time for me (i.e., the Hosts file blocks the Verisign site). I will try to test it more thoroughly this weekend.

Are you sure that the Hosts file is not queried again? I have no idea about the exact operation of DNS servers and how they handle wild-card redirection, but is it at all possible that at some point in the communication between the browser and the DNS server, that the browser finds itself needing to resolve the Verisign URL and refers to the Hosts file at that point?

Also, could different versions of IE (or different settings) affect the behavior? How about Proxo - would it affect any of this?

Just asking some dumb questions ... Meanwhile, I will keep trying to see if I can force my browser to be redirected to Verisign despite my Hosts file entry ...

I would guess not -- but anyone speak up if I am FOS.

I was taught the default "Name Resolution" process works thusly:

• The user enters a "name" on the address bar
• the browser then queries different sources to find the number
• the usual sequence is:
  1. the DNS cache stored in RAM
  2. your HOSTS file
  3. your web-based DNS server
• Once it is presented with a numerical address, the search is over. It does not take the numerical address, covert it BACK to a name and then start the process all over again. Once it has a number, it is done.

So, if the non-sense name is NOT in your DNS cache or NOT specifically entered letter-for-letter in your Hosts file, then your computer will retrieve the number from your DNS server -- and it will get 64.94.110.11. Once it has the number, it will initiate an HTTP connection with that number.

Your computer does NOT know that the number it received belongs to "VeriSign SiteFinder". All that it knows is the name you entered resolves to that specific number. It does NOT do "reverse DNS" to resolve the number BACK to a name, and then re-query your Hosts file to see to what number this NEW name resolves.

If you don't enter EVERY SINGLE mis-spelled word in your Hosts file (quite challenging), then I don't see how a Hosts file is going to help you...

---

On the other hand, you should be able to modify your Routing Tables so that your computer cannot reach that numerical address. I don't believe anyone has mentioned that...

[text was edited by author 2003-09-20 08:55:59]

Here's another item for the discussion. As I was reading this thread last night, I decided to block the two addresses in my routers (BEFSX41). Before doing that, I entered a "wrong" url and got, as expected, sentto the Verisign page (some of their suggestions for the right URL were quite far out...this could be another thread ).

Then I took a look at LinkLogger. Remember, this is without any blocking of the Verisign addresses.

Hmmmmm

Addendum...I've got as dynamic ip, so the one that I forgot to black out belongs...to someone else today. sorry!

Actually you can change the order in which the "Name Resolution" process runs in. Atleast in IE its stored in the registry and can be modified



R2 could you please post how one would modify the Routing Table so that my computer cannot reach that numerical address thanks.

KhaineBOT

Well, just playing around for a few minutes ...

(1) Do Not Search From Address Bar is enabled, and both Verisign URLs are included in my Hosts file:

If I type hxxp://www.qweqweasdfgzxcvb.com in my Address Bar and hit Enter, the status bar initially displays Connecting to site 64.94.110.11 for several seconds while the progress indicator acts as if the page is slowly loading. After about 8-10 seconds, the status bar message changes to Connecting to site 127.0.0.1 and a second later IE loads the standard Dnserror.htm page.

(2) Do Not Search From Address Bar is enabled, and both Verisign URLs are removed from my Hosts file:

If I type hxxp://www.qweqweasdfgzxcvb.com in my Address Bar and hit Enter, the status bar intially displays Connecting to site 64.94.110.11, then after a few seconds, the status bar message changes to Connecting to site 12.158.80.10 and the Verisign page eventually loads.

----------

(Note: "hxxp" represents "http"). So, even though the IE browser and DNS server are supposed to be performing the exact same function in both cases, the presence or absence of the Verisign URLs in the Hosts file definitely appears to affect what actually happens. I tried to make sure the cache and history were empty before each attempt, and I don't think I have anything else that might interfere - it's a Win98se system, ZA Free firewall, no Proxo, no router. I don't understand why it should or shouldn't happen, I just wanted to make the point that on certain systems (for whatever reason), adding those two URLs to a Hosts file does appear to thwart the Verisign redirect ...

said by Reverend Ike:

---

If I type hxxp://www.qweqweasdfgzxcvb.com in my Address Bar and hit Enter, the status bar initially displays Connecting to site 64.94.110.11 for several seconds while the progress indicator acts as if the page is slowly loading.

---

This is the first connection which isn't blocked by hosts and results in a redirect.

said by Reverend Ike:

---

After about 8-10 seconds, the status bar message changes to Connecting to site 127.0.0.1 and a second later IE loads the standard Dnserror.htm page.

---

This is the second connection (the redirect) that is blocked by hosts.

I don't know if you use Proxo but you should use it at least temporarily so you can see what's actually happening in the log window. You will see both connections.

OK, I think I'm understanding it a little better. What fooled me is the fact that nothing changes in the IE window (other than the status bar message) while the first site (64.94.110.11) is loading/redirecting. In other words, if I have Google's home page up, and type a nonsense URL in the Address Bar, the Google page remains unchanged until the error page loads at the end of the process. Because I didn't see anything visibly change, I thought the first site was never reached.

But it seems that what you're saying differs from what R2 was saying - you're saying that when the redirection occurs, a new Hosts file lookup also occurs, and so the second connection is being blocked by the Hosts file. If that's true, then the Hosts file is being at least partially effective, in that the Verisign page (and its links) are not being displayed.

Correct me if I've still got it all wrong ...

said by Reverend Ike:

---

But it seems that what you're saying differs from what R2 was saying - you're saying that when the redirection occurs, a new Hosts file lookup also occurs, and so the second connection is being blocked by the Hosts file. If that's true, then the Hosts file is being at least partially effective, in that the Verisign page (and its links) are not being displayed.

Correct me if I've still got it all wrong ...

---

Not at all. You see the first connect is addressed by IP so since the IP has already been obtained, hosts isn't consulted again. But when the redirect occurs, now we are beginning with a hostname whose IP is unknown. Hosts is read, the hostname is matched. 127.0.0.1 is returned as the IP thus blocking the second connection out. To say it is partially effective isn't so at all because by that time you have already been tracked by the first server.

I'm sure they thought this was an absolutely brilliant scheme to thwart hosts blocking but I have seen more devious tactics than this.

With hardware firewall it's very easy to do. Just adding verisign.com to blocked domain list solves their "feature" problem.

All your base...

PS. Fw is webramp 700s with Sonicwall firmware.

said by LowWaterMark:

---

Host file entry works fine on this one: »www.hsdjsckjsjktgdfw.com/

---

The hosts file solution worked for me in a simple test. I'll have to read a bit more in this thread. Now, before I get caught up in all of this:) - I suppose I should also go read why this Verisign thing is so evil...

----
EDIT: Further tests corroborate hpguru's illustration above. In any event, the Verisign's sitefinder page does NOT come up at all. In every instance I get "Action canceled" :::Isn't this enough?:::

[text was edited by author 2003-09-21 08:07:56]

When I referred to "partially effective", I just meant that the Hosts file would prevent the second webpage (hxxp://sitefinder.verisign.com/index.jsp) from loading - therefore the user would not be able to access the Verisign search tool, or click on any of the Verisign links (Travel, Entertainment, Gambling, etc.). I don't know how important that is to Verisign, or if Verisign derives significant revenue or benefits from people using those links, but I thought there was some value in the Hosts file shielding the user from being able to use that page.

From your earlier explanation, I finally understood that the Hosts file can do nothing to prevent a connection to the first address (64.94.110.11 / sitefinder-idn.verisign.com).

Hopefully, ICANN or someone will derail this arrogant move by Verisign. It's amazing that a really dumb idea, on a huge scale like this, manages to get to the point of implementation without someone scratching their head and saying "Erm, maybe we should think about this some more ...". The Intuit/C-Dilla debacle is a drop in the bucket compared to this Verisign stupidity ...

said by Reverend Ike:

---

When I referred to "partially effective", I just meant that the Hosts file would prevent the second webpage (hxxp://sitefinder.verisign.com/index.jsp) from loading - therefore the user would not be able to access the Verisign search tool, or click on any of the Verisign links (Travel, Entertainment, Gambling, etc.).

---

In the first connection is there tracking information being transmitted back and forth as a result of this connection? A cookie? I feel the outrage but I'm trying to understand it.

I don't know about a cookie, but I believe your IP address and user agent information (unless altered) would be transmitted as with any website, and I assume the site name that you entered in the Address Bar might be transmitted as well.

It's not clear whether this is an attempt to collect and compile such information, or more of a search page hijacking, where the main objective is to get people to use the Verisign search tool and click on links found at the second address ...

you will get a cookie from the 3rd connection!
207.net

said by Nam Vet4:

---

you will get a cookie from the 3rd connection!
207.net

---

You are correct.

Sorry to run away -- I was busy all day. You could enter that site (207.net) in your Restricted zone to prevent the cookie.

I have a very difficult time analyzing what happens after the "redirect" -- because for some reason I never seem to get there (I get that "DNS Error" screen I mentioned above).

If there is a redirect to a new, non-numeric IP address, then the Hosts file could be useful. If VeriSign wanted to be sneakier, they could do the re-direct to a numerical IP address -- again bypassing your Hosts...
__________

The routing tables in Win9x are usually controlled through DOS and the "route" command (if memory serves). I don't know how someone might modifying routing tables in WinXP -- that might need to be asked in a different thread. I simply don't know.

Excellent!

Now... cannot someone use the Hosts file to redirect to Google -- instead of to 127.0.0.1 or 0.0.0.0?

At least one google address is: 216.239.57.99. Now... that will not cause Google to SEARCH for the bogus site, but it would prevent you going to VeriSign and give you a useful search page.

Correct?

said by Nam Vet4:

---

you will get a cookie from the 3rd connection!
207.net

---

I believe the actual site is

2o7.net (two, the letter "o", seven)

... which was already in my Restricted Zone thanks to IE-SPYADS.

you are correct, I mistyped it.

This is all very interesting, but it still pisses me off to no end that we have to block this traffic rather than some authority placing an injunction on Verisign. I was very well pissed off with the Microsoft version of a DNS error but this really kills me. I feel like pulling the domain names that I have them as registrar for away to a new registrar. Grr..