Verisign seal sometimes means "no encryption"
THE GRAPHIC seal from security firm Verisign should be a synonymous for security, for "peace of mind", or at least that's what the firm has been aiming for since the inception of the web. However, little seems to happen to those that display it yet seem to be an example of insecurity.
It all started when this scribbler wanted to contract a mail forwarding service. Seven years ago, I used to be a customer of Miami, FL based firm Skybox, and when the need arose once again, selecting them was a no-brainer, so I headed to the firm's web site and decided to sign up. An offer there promised a 50 per cent discount rate on the yearly fee if I contracted it before November the 30th. Good.
The trouble began when I clicked on the "sign up" form found at the firm's web site which did not switch to a secure connection, and seemed to handle credit card data over an unencrypted connection, all this while displaying in several instances the Verisign seal and while claiming on the same pages "Secure transaction", and then "all the information and transactions that you realize with your credit card are properly protected".
I tried manually changing the URL from http:// to https:// but it wouldn't connect: the web server refused SSL connections. I proceeded then to e-mail the firm telling it of the huge security implications of handling customers' credit card data without SSL.
A day later, there was still no reply. So I headed to the web site of security firm Verisign, which sports a "seal misuse report form", described as a way to "Report abuse of the VeriSign Secured Seal to VeriSign. I quickly filled a report on the site. It was Tuesday the 27th.
I expected the firm to take quick action and expected a reply on the subject. But days passed and there was still no reply whatsoever, and the Skybox web site kept refusing https:// connections and displaying the sign up form including credit card entry fields over an unsecured http:// connection, so I decided to ask what enforcement does Verisign offer to the firm's PR contact.
Well, suffice to say that I'm writing this on Friday night, and still there has been no reply from Skybox customer support, no response from Verisign after filling the "seal misuse report", and there was no reply to my e-mail to Verisign's PR department.
I received return receipt notifications indicating that my e-mail was indeed read by two people at Verisign's PR dept on Thursday morning, GMT-5 time, but no reply has been received as of this writing. I can only look at the sky and wonder... Internet web security is in charge of exactly who? µ
Share this:
ShareBusiness Intelligence Software
Customer Relationship Management (CRM)
Enterprise Accounting Software
Enterprise Resource Planning (ERP)
Enterprise Systems Management
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.
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?
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.
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...
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/
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.
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.
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!

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.
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....
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)
http://www.skybox.net/Login.aspx?ReturnUrl=%2fmiskybox2.aspx
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.
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.