Re: Update on Webcall.ca concerns

Scott Walde wrote:
> Andrew, do you want to add anything? ;-) (without the recent
> re-subscription, I might not have put 2 and 2 together.)
>
> ttyl
> srw

Through this whole thing I've been biting my tongue, but probably no
real point in doing that any more, I've been outed :)

Note that everything I say here is my own opinion and is not an official
response from Sasktel and is not endorsed by them in any way.

Okay, on to the topic at hand. Yes, I originally built the server side
of the Webcall setup CD, as well as helped out some parts on the CD
itself, as well as being part of the entire design of the automated
install/setup and TFTP/configuration server.

The original setup involved the server and CD negotiating and encrypting
all traffic to do the initial configuration of the ATA. It even set up
the encryption using a zero knowledge test to ensure that even the
encryption key was not passed back and forth, and thus susceptible to
sniffing. Everything over public wire was encrypted. The actual
configuration of the ATA happened insecurely, but at that point the ATA
would be hooked up to your PC directly via ethernet.

Since there is no security on TFTP, and it was the only protocol the ATA
could use for automatic updates, we made sure that nothing secure was
stored in those configuration files. At least, not long term. Yes,
there were situations we could see where the help desk would need to put
information like the SIP username/password in the file, and then have
the customer hard boot the ATA which would cause it to request the
configuration files again, thus resetting a mis-configured username or
password.

There were a couple checks in place at one time to ensure that
information like this was not stored in the configuration files long
term, but obviously things changed. I haven't been involved in the
project for nearly two years, so I'm not sure when, or where things went
wrong. However, when I did hear about the issue, after muttering a few
choice phrases, I made sure those involved were informed, and as I
understand, they had the issue resolved in around 24 hours.
Received on Mon Dec 18 21:55:32 2006