Another problem I just discovered with the Authorized Reseller Seal is that it appears to ignore path information in the URL. This might be part of the existing problems with the seal CGI's definition of a URL, but I've found that if http://www.it.ca/ serves a seal with a signature built for "www.it.ca/path/to/arbitrary/data", it gets authenticated.
Also, the seal management system converts all URLs to lower case. That's fine if they're just hostnames and hot really URLs, but it could cause problems if you're really trying to authenticate against the referrer rather than just the hostname portion of it. One more thing is that changing the "URL" on the management page does *not* cause the resultant signature to change. So presumably a signature is created *once*, when the seal entry is created, and is not expired when the entry which it's supposed to authenticate changes. You can see this in action at http://www.it.ca/bogus/ . And https://www.it.ca/bogus/ demonstrates how the SSL lookups fail. Perhaps all this will be fixed by the time this stuff is announced in a Live Reseller Update? :) On Tue, Oct 15, 2002 at 01:18:33AM -0400, Paul Chvostek wrote: > > On Mon, Oct 14, 2002 at 05:01:46PM -0700, Tom McDonald wrote: > > > > This is a program which allows you to place the "Tucows Authorized > > Reseller" logo on your site. Clicking the image (if placed on your > > site) would bring up a validation that you are indeed a valid Tucows > > reseller. You need to register each URL where you plan to place the > > image if I understand things correctly. If you have none registered > > so far you must initialize first with the option of adding more URLs > > going forward. > > The Seal program is a potentially useful marketing tool for some; Tucows > gets a link on the reseller's site and the reseller gets an easy method > to demonstrate his affiliation with a large, established and well-known > company. But the technical stuff behind the seal still needs some work. > > Some bits appear to be unfinished. The management tool has a user > interface inconsistent with the rest of the OpenSRS product line. And > it's not behind SSL, which wouldn't be so bad except that the link from > the RWI goes to a CGI that simply redirects you to an unencrypted URL > that includes a static password in the GET. So your management access > to this part of your RSP profile can be compromised by anybody running a > URL sniffer. There are lots of ways this problem could be avoided -- > one-time-only passwords, a check back to rr-n1-tor for the existence of > a session, or getting a certificate for the host "referrals.tucows.com" > (Tucows DOES do certificates, right?) but it appears the development > didn't get that far before the product was launched. > > Others bits appear simply to be broken. The seal doesn't seem to work > from within an SSL page. And if the host lookup fails (as is the case > if you point to the seal from an SSL-encrypted page), the pop-up window > is the wrong size, and shows up with scroll bars that could be avoided > easily with just few lines of CSS. > > And I'm sure as heck not going to put up a seal like this with the > existing technical errors in its output. They're calling things like > "www.it.ca" a URL fer gosh sakes. Where's the service type? Where's > the path? Did nobody at Tucows think it would be important to present > *accurate* information when authenticating resellers? Did somebody > forget what a URL is? Or if "www.it.ca" really IS the thing you're > authenticating, why not just call it a hostname? > > I suspect further testing would have been in order prior to launch. > And perhaps better communication with the beta testers, who I'm SURE > would have communicated some of this stuff pretty early on. > > Not to mention that the server from which this product is being served > seems to be running outdated (and possibly even vulnerable) versions of > Apache and mod_php. Heck, rr-n1-tor.opensrs.net is even running old > versions of Apache and OpenSSL with known buffer overflows. > > Let's get our house in order before we try to sell it, hmm? > > Somebody needs to be taking care of this stuff BEFORE pushing the launch > of new security- and trust-related products, or Tucows just looks silly. > > -- > Paul Chvostek <[EMAIL PROTECTED]> > Operations / Abuse / Whatever +1 416 598-0000 > it.canada - hosting and development http://www.it.ca/ -- Paul Chvostek <[EMAIL PROTECTED]> Operations / Abuse / Whatever +1 416 598-0000 it.canada - hosting and development http://www.it.ca/
