I have had the exact same experience, when I was planning to book a hotel in Dubai. The website has the "Verisign secured" logo very visibly all over the place on all pages, but there's no sign anywhere about https, and credit card info is asked on a nonencrypted page. (And no, the form submit action target isn't an https page either.)

And to all of you commenting - especially mr. Piggott - the "report misuse" link in the Verisign logo "verification" popup specifically states: "We are particularly interested in the following types of misuse:
- The site does not employ an appropriate VeriSign service (...)".

The interest however seems lame to me, I never received any acknowledgement of my report either. I suppose they make too much money selling the rights to display that "Verisign secured" to really care.

Several people pointed out that I was 'wrong' about my comments about SSL. My point was that showing that the form page is not running from SSL (with loads of screen shots as 'evidence') does not inherently show a security flaw, that was all. I think my comment about serving form pages as non-SSL being 'more correct' was probably a bit misguided, because as several people have pointed out it is difficult to tell if the submit page is via SSL. My argument was of course also somewhat undermined by the fact that apparently the submit page wasn't using SSL (the page was down when I tried to investigate this) so perhaps I could have sounded a bit less arrogant.

http://www.skybox.net/Login.aspx?ReturnUrl=%2fmiskybox2.aspx

https://seal.verisign.com/splash?form_file=fdf/splash.fdf&dn=WWW.SKYBOXUSA.NET&lang=en

Read what's on that page. They do use verisign services, but only on pages that start with "https". (it says that)

Hi,
I had a brief look at this using a firefox plugin...livehttpheaders...

This shows one https connection on the page to dowload a gif?(https://www.lanboxusa.com/images/fondo_forms4.gif
) Very bizarre, but seems you are correct that the form is not https encrypted. Very naughtie of them. I think they have a duty of care for their customers. Maybe contacting your credit card company might reveal more details, as they have "standards" on securing credit card data/transactions on web sites. 

Final caveat, I did not post real data, so maybe they have some client side checking that does not allow connections to https with invalid data, but to be honest I doubt it....

Well excuse me, but the "bunch of textfield elements" that you refer to happen to contain credit card numbers and secret hash, information that I very much prefer be encrypted, even if that insults your sense of usefulness.
I may have nothing to hide, but my credit card details are still something that I prefer stay secret as much as possible, thank you very much.

Hey Jim Moores,

your principally right about that, but have a look at the source code... the target of the form is not an encrypted site eighter!


Jim Moores, you are wrong. See this for example:
http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx

The user has no way of predicting whether the form post uses https or not. The uset has no way of knowing that the form itself came from the right place, etc, etc.

Fernando Cassia is correct. I would _never_ enter any personal information in a non-https page.

Jim, the action page for the first part of the form, at least, wasn't an https page. So the page the form was directed at wasn't encrypted either. The data was going out unencrypted. And, on the form page, the verisign symbol was displayed.

I use a mail forwarding company called Bongo International http://www.bongous.com. They have always been very professional with me and I have never had any issues. Check out this analysis. It compares all the big mail forwarding companies in the US. I don't think Skybox was even part of the analysis. 
http://shipping-guru.tumblr.com/

The problem is that this article shows huge misunderstanding in the way SSL works and when it is necessary. 

The page carrying the HTML with the form you fill out DOES NOT need to be delivered over https. 

Why does the code laying out a bunch of textfield elements need to be delivered encrypted? 

It is only the forms submit action address that needs to be to an https:// address. What they are doing is actually more correct than the usual thing that developers do which is to assume that consumers are stupid and mistrustful and encrypt the form page as well as the submit. 

It puts more load on the servers, but results in fewer articles like this one...

If you use a credit card, you ARE protected. If you see anything funny turn up on your next statement, just call up your credit-card company and query it. What they tend to do is just reverse the transaction, then leave it up to the merchant to respond and explain why they should be paid.

Besides, most thefts of credit-card numbers happen from the merchants' database systems, so using an SSL-encrypted connection to the website is doing nothing to strengthen the weakest link in the security chain.

I can't help but think that you are reading too much into the presence of the Verisign logo on a non-secure http connection.

Verisign offer many different services to their clients, from digitally signing apps to offering secure web services.

The presence of the logo could be down to some service they are using, that is not related to the state of encryption on the main site.

If that is the case, I am not particularly surprised you have not 'still' had any replies.

I do however agree with your original premise, that credit card data sould not be transferred over a non-secure connection, ever.

Example, If you bought a Rover, but it had say a Porsche engine in it, and the front badge fell off, would you go to Rover or Porsche?

This is where it would be good for Firefox to 'detect' is you are entering a credit card number (perhaps by use of some algorithm) and warn you if the site is not enrypted

If you use a credit card, you ARE protected. If you see anything funny turn up on your next statement, just call up your credit-card company and query it. 

What they tend to do is just reverse the transaction, then leave it up to the merchant to respond and explain why they should be paid.

Besides, most thefts of credit-card numbers happen from the merchants' database systems, so using an SSL-encrypted connection to the website is doing nothing to strengthen the weakest link in the security chain.