Teliax DOA ?

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.

VoipJet has a server on the West Coast:

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

They appear to have fixed it now...

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

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.

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.

for a copy of Ari Luotonen's original draft, 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

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

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

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

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

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

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 security hazzards?