«

Anyone have experience with Teliax VOIP services? I ask because we
tried to sign up and found there was no there there.

They do have a very nice website, and a nice list of features, however,

* The form under <https://www.teliax.com/newaccount/> is broken with
PHP errors.

* This form also lists your full credit card number, expiration, and
everything else as part of the submit URL, _very_ insecure.

* The phone number listed on website has returned a busy signal for
several days now.

* The website's "live help" also says "there is one support call
queued before you". That call has apparently also been in the queue
for several days.

* The teliax.com domain has only two DNS nameservers and they're
both on the same /26 subnet. Neither has valid rDNS. The subnet is
registered to a "David Comean" and appears to a single FreeBSD server
in a "RockyNET" colo. At least one of the upstream providers is Yipes
(well known as a spamhaus).

From all appearances there is no company behind the website. Is this
some kind of front to a VC scam?

Fred

Fred Friedman <> writes:
> From all appearances there is no company behind the website. Is this
> some kind of front to a VC scam?

There is no doubt that teliax is a very small company that is still
learning how to do basic machine administration. I too noticed all
the DNS problems you mentioned and still went with them. They do have
a reasonably good deal on pay-per-minute service and DID numbers.

At this point in time, it is relatively hard to find companies that
offer DID'S in the SF Bay area and have a sip server within a few ms
of the bay area.

-wolfgang

* I have to admit, I only noticed the CC in URL issue long after I
signed up. Yikes.
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/

Wolfgang S. Rupprecht wrote:
> Fred Friedman <> writes:
> > From all appearances there is no company behind the website. Is this
> > some kind of front to a VC scam?
>
> There is no doubt that teliax is a very small company that is still
> learning how to do basic machine administration. I too noticed all
> the DNS problems you mentioned and still went with them. They do have
> a reasonably good deal on pay-per-minute service and DID numbers.
>
> At this point in time, it is relatively hard to find companies that
> offer DID'S in the SF Bay area and have a sip server within a few ms
> of the bay area.

VoipJet has a server on the West Coast:

http://www.net.berkeley.edu/cgi-bin/...te?69.25.60.30

But as you say, they don't offer DID numbers, and supporting only IAX
and not SIP one can't even use the free service by Ipkall, which
appears to be further North on the same coast, in Washington State

Enzo

Fred Friedman wrote:
> Anyone have experience with Teliax VOIP services? I ask because we
> tried to sign up and found there was no there there.
>
> They do have a very nice website, and a nice list of features, however,
>
> * The form under <https://www.teliax.com/newaccount/> is broken with
> PHP errors.

They appear to have fixed it now...

> * This form also lists your full credit card number, expiration, and
> everything else as part of the submit URL, _very_ insecure.

Why? The security is the same as for a POST submission (although,
double-charging might more easily occur if the "Back" button takes
again the browser to that page). If the destination page, and, for
server authentication reasons, the page where the "submit" button is,
are secure, SSL protects the card number regardless of the method used
to submit the form.

Enzo

Enzo Michelangeli <> wrote:
>> * The form under <https://www.teliax.com/newaccount/> is broken with
>> PHP errors.
>
>They appear to have fixed it now...

It's a multi-part form. Did you follow it through to the end?

>> * This form also lists your full credit card number, expiration, and
>> everything else as part of the submit URL, _very_ insecure.
>
>Why? The security is the same as for a POST submission

No, this is incorrect. POST data is not sent in the URL, does not get
cached by browsers, is not logged by proxy servers, and is encrypted.
GET data (transmitted in the URL), in contrast, is not encrypted
regardless of whether you use SSL (https) or not.

Fred

Fred Friedman wrote:
> Enzo Michelangeli <> wrote:
> >> * The form under <https://www.teliax.com/newaccount/> is broken with
> >> PHP errors.
> >
> >They appear to have fixed it now...
>
> It's a multi-part form. Did you follow it through to the end?

You mean clicking on "continue"? I did it a few days ago when I
subscribed, and I didn't notice anything strange. Now I've gone (with
Firefox 1.0.4) up to the step 4, stopping there because I don't want to
enter fake data, and it appears to work fine.

> >> * This form also lists your full credit card number, expiration, and
> >> everything else as part of the submit URL, _very_ insecure.
> >
> >Why? The security is the same as for a POST submission
>
> No, this is incorrect. POST data is not sent in the URL, does not get
> cached by browsers, is not logged by proxy servers, and is encrypted.
> GET data (transmitted in the URL), in contrast, is not encrypted
> regardless of whether you use SSL (https) or not.

Yes it is. The URL is not transmitted at all: first a TCP connection is
established, then the SSL security is negotiated, and only then does
the client send a "GET" specifying the local part of the URL and, in
HTTP 1.0 or higher, the hostname in a "Host:" header.

This is true even when there are proxies in the path: see e.g.
http://crypto.stanford.edu/~eujin/ss...cknowledgments
and, for a copy of Ari Luotonen's original draft,
http://www.web-cache.com/Writings/In...nneling-01.txt
.. If that scheme was not followed, the client couldn't possibly
validate the server certificate (and that's intentional, in order to
defeat possible Man-in-The-Middle attacks by intermediate proxies). The
only place where the URL could possibly be logged is the target web
server, which is supposed to be secure.

Enzo

Fred Friedman <> wrote:
> Enzo Michelangeli <> wrote:
>>> * This form also lists your full credit card number, expiration, and
>>> everything else as part of the submit URL, _very_ insecure.
>>
>> Why? The security is the same as for a POST submission
>
> No, this is incorrect. POST data is not sent in the URL, does not get
> cached by browsers, is not logged by proxy servers, and is encrypted.
> GET data (transmitted in the URL), in contrast, is not encrypted
> regardless of whether you use SSL (https) or not.

GET arguments in https requests are not logged by (or available to) proxy
servers, and they are encrypted from end to end. Stop and think for a moment
about how the https protocol works.

The only thing worth worrying about is that they are often cached by
browsers. And, I suppose, they appear in raw server log files if the server
operator makes those available, in which case they've probably got bigger
problems.

miguel
--
Hit The Road! Photos from 36 countries on 5 continents: http://travel.u.nu
Latest photos: Queens Day in Amsterdam; the Grand Canyon; Amman, Jordan

Enzo Michelangeli <> wrote:
>> Enzo Michelangeli <> wrote:
>> >> * The form under <https://www.teliax.com/newaccount/> is broken with
>> >> PHP errors.
>> >
>> It's a multi-part form. Did you follow it through to the end?
>
>You mean clicking on "continue"? I did it a few days ago when I
>subscribed, and I didn't notice anything strange. Now I've gone (with
>Firefox 1.0.4) up to the step 4, stopping there because I don't want to
>enter fake data, and it appears to work fine.

You did not follow it through then. If you had you would see that it
was down.

>The URL is not transmitted at all: first a TCP connection is
>established, then the SSL security is negotiated, and only then does
>the client send a "GET" specifying the local part of the URL and, in
>HTTP 1.0 or higher, the hostname in a "Host:" header.

Thanks for the correction, and referring URL. I was wrong about the
encryption of GET data and apologize. Still not comfortable with the
needless use of cacheable credit card info but at least it's not
sniffable at the packet level.

Fred

Fred Friedman <> writes:

>>> * This form also lists your full credit card number, expiration, and
>>> everything else as part of the submit URL, _very_ insecure.
>>
>>Why? The security is the same as for a POST submission

>No, this is incorrect. POST data is not sent in the URL, does not get
>cached by browsers, is not logged by proxy servers, and is encrypted.

Because it's encrypted (SSL), proxy servers can't see it anyway (without
a lot of effort).

I'm a little annoyed that they send standard (unencrypted) e-mail with
much of that same information along with a message that says that it's
all encrypted.

--kyler

Kyler, what is being sent in the welcome email that has securit
hazzards