Slashdot Mirror

Even though the DDOS root server survived yesterday, I'm sure its still vulnerable. BTW, here are some links that you Slashdotters might find interesting...be sure to click on them many times; they may not work right if you don't:

FREE ATI RADEON 9700 PRO CARDS! NO LIMIT PER PERSON!!! CLICK MANY TIMES NOW!

GET PAID FOR USING AMD PROCESSORS!

THE BEST LINUX DISTROBUTION EVER!!!

COMPLETE OPEN SOURCE CODE FOR WINDOWS!

Verisign, home of the root server.

Even though the DDOS root server survived yesterday, I'm sure its still vulnerable. BTW, here are some links that you Slashdotters might find interesting...be sure to click on them many times; they may not work right if you don't:

FREE ATI RADEON 9700 PRO CARDS! NO LIMIT PER PERSON!!! CLICK MANY TIMES NOW!

GET PAID FOR USING AMD PROCESSORS!

THE BEST LINUX DISTROBUTION EVER!!!

COMPLETE OPEN SOURCE CODE FOR WINDOWS!

Verisign, home of the root server.

You mean, Veriswine.

Network Solutions competes for this business with its NetDiscovery service. "The VeriSign NetDiscovery Service is the premier choice in the marketplace for a full turn-key solution for provisioning, access, and delivery of call information from carriers to law enforcement agencies (LEAs)." This is built on Verisign's control of the inter-carrier SS7 network that controls the phone system. Verisign acquired Illuminet and took over that business several years ago.

None of this is a secret, and you can even read the technical specs about how it's done. What's striking, though, is how much easier wiretapping is today. It used to be inefficient and expensive for law enforcement to wiretap. (New York Telephone was at one point back in the 1980s billing the FBI about a million a year for wiretaps, each one charged as a leased line.) Now, it's easy, and the carriers have to eat the costs. This encourages far broader wiretapping.

Network Solutions competes for this business with its NetDiscovery service. "The VeriSign NetDiscovery Service is the premier choice in the marketplace for a full turn-key solution for provisioning, access, and delivery of call information from carriers to law enforcement agencies (LEAs)." This is built on Verisign's control of the inter-carrier SS7 network that controls the phone system. Verisign acquired Illuminet and took over that business several years ago.

None of this is a secret, and you can even read the technical specs about how it's done. What's striking, though, is how much easier wiretapping is today. It used to be inefficient and expensive for law enforcement to wiretap. (New York Telephone was at one point back in the 1980s billing the FBI about a million a year for wiretaps, each one charged as a leased line.) Now, it's easy, and the carriers have to eat the costs. This encourages far broader wiretapping.

Frankly, I'd be very happy if public key encryption became standard, and there were government-registered companies to certify people's public keys. How do you know that this key purportedly from John Smith is really from John Smith? Why not welcome the government's seal of approval that the company verifying John Smith's identity isn't "Fly-By-Night Enterprises"? Or are you happy trusting Microsoft to verify this stuff for you?

How come it's so easy for someone to transfer a domain registrar via social engineering and yet it's so hard to do it legitimately?

My recent attempt to move a domain from Verisign to Namesecure ended up taking the domain off the air for over a month... Namesecure has completely dropped telephone support -- their email support being consistently unhelpful and clueless I ended up moving the domain to Register.com instead.

I have to sign up for a Verisign test server certificate every two weeks. As part of this, I have to agree to a lengthy service agreement displayed in an editable TEXTAREA. Of course, I always delete the contract text before agreeing to it.

Not only that, but their pricing is exorbitant. $900 for a 128-bit SSL cert? For our next SSL certificate, we're going with GeoTrust, who sells a 3-year cert for $300.

Fuck verisign! Thawte (aka verisign) also!

VeriSign, Inc. (Nasdaq:VRSN) is the leading provider of digital trust services that enable businesses and consumers to engage in commerce and communications with confidence.

Info for readers to learn more of what was really their greatest sin: the retroactive selling of customer's emails and phone numbers from the whois database.

The details:
-A complete copy of all the personal information in the whois database was sold.
-Each copy was sold for $10,000--made payable to the company.
-The list was retroactive, selling the info of all the existing customers, not just the new ones signing up after the sell announcement was made.

It doesn't seem to have been archived by many of the usual news outlets. Here is a coverage of it from the Washington Post at the time (about half way down is the mention of them selling the customer contact data to anyone wanting it):

Washington Post article

But this link is the real kicker: the VeriSign tagline motto, considering these types of shady dealings with their customers: The service-marked VeriSign tagline

Things to note (strategic):

None of SOAP, WSDL, UDDI, and now WS Security are "Royalty Free".

SOAP isn't a de jure standard -- it's a W3C "note".

UDDI was supposed to move into an open standards body in 2001 but still hasn't.

By publishing WS Security on their websites and through no open standards body we see Microsoft, IBM and that other company abandoning even attempts to appear open.

On the technical side -- if you want to see a little deeper into the security issues left unsolved by SOAP, I recommend you look at the OASIS technical committee specification, ebXML Message Service Specification version 2.0 rev C.

Actually, for a 128-bit Cert, you need to pay Verisign $895 now. A complete scam. Next time my company is in the market for a cert, we'll be trying GeoTrust which I believe acquired Equifax's Certificate division, and has FAR more reasonable prices.

If we consider that Thawte is selling their 128-but SuperCerts at the price of US $300 per year, which is not even the highest price on the market (Verisign, $348, then:

it is completely understandable that the price is similar, as they are supposed to go into similar actions to verify the authentity of the registrant - or atleast this is what their marketing speach makes you think - that they only give this domain name for fully qualified registrants, this they can verify only by same procedures, as Thawte or Verisign. They sell different product, but need to do similar procedures to deliver the product

What is not understandable, is if their price for renewals is as high - as the work involved in renewal is minimal compared to first time granting. This is also the case with Thawte and Verisign, they charge way too much for the renewals too (Thawte, $300 Verisign $249 )

The first step (really!) is to get a security policy in place. This really doesn't have to be anything special-- but it does need the buy-in of ALL groups affected (sysadmins, developers, marketing, sales, executives, etc.) That's really the only hard part.

Probably the quickest way to get started is to head to the SANS security policy project and adapt their sample policies to your company. This is one of those rare cases where it's more important to get something in than it is to get it right the first time. Policies can be changed fairly easily-- but you don't want to go to all the trouble to implement a secure environment only to have someone on the inside fighting you every step of the way.

Now the fun part-- actually securing your systems. Here are some pointers on places to start:

1) Review the SANS "top 10" security vulnerabilities and make sure they're covered.

2) Review Lance Spitz's excellent collection of host security information and make sure to follow his recommendations.

3) Make sure your firewall rules are set up with the security best practice of "minimum access to get the job done". Far too many firewalls allow traffic they shouldn't.

4) Get NMAP, a network mapper, port scanner, and OS identifier and run it from the Internet to your exposed (i.e. DMZ) hosts. Also run it from your exposed hosts to your internal network to validate that only the traffic that should get in can get in. (The traffic allowed back in from your DMZ should be very little, preferably none.) If you find anything that is inconsistent with what you think should be happening, check your firewall rules again.

5) Grab a copy of the Nessus security scanner and run it against your newly secured systems. If it finds anything, read the description of the problem and see if it's something you can fix. You can bet that everything you find here will also show up on your "security audit" since most "audits" are just someone running a tool like this and then feeding the output to the consultants to make it all pretty for management.

6) You should have most of the obvious, widespread holes plugged by now. This would be a good time to get some sysadmins out to some classes. Verisign has a number of excellent general Internet security classes. I'm sure there are lots of other good places, too. I was pleased with Verisign because of their Internet focus. Too many security classes only concentrate on host security and neglect network security.

7) Get the application developers at your site to read and follow Dave Wheeler's writing secure programs guidelines. This is a lower priority than OS/network security since these holes are likely to be specific to your site only. Only a determined hacker is likely to find and exploit them-- however exploiting application bugs/holes can severely disrupt your business. What happens when an electronic data interchange transaction gets bogus data inserted? How far will that bogus information make it in before it's detected? In the worst case these bugs could result in people getting free products/subscriptions, stealing credit card info, or destroying data inside your systems.

8) Now it's time to get that audit. They will be able to tell you what you missed in the previous 7 steps. Why wait so long? Most places will keep looking until they find something to report. If you do this too soon, the subtle security problems will be lost in the noise of all the obvious problems the previous 7 steps would have fixed. If you do this last, only the "hard" problems are left for them to find.

Remember above all that this is an ongoing process. Keep current on your patches, and repeat all the above steps regularly to keep all the bad guys away.

I only started seriously looking into "web services" yesterday, so I'm a newbie. However, I think I can poke some holes in the poster's arguments.

They also require that a Web Services directory server (UDDI) be available

You don't need a UDDI server to run "web services," whatever they are. Google's SOAP service seems to work just fine without the use of a UDDI server. You don't need a discovery server if you've already discovered the service you want to use.

No standards yet exist for Web Service security

How about SSL, HTTP BASIC-AUTH, XML Signature, Digital Signature for SOAP, SOAP Encryption, XML Key Management Specification... Also in the news recently is a major proposal, WS-Security. Also read the press release about other upcoming proposals. I don't know a lot about many of these specs, because as I said, I've only been looking into this stuff for one day. However, it looks like there is a lot of effort here, so if some of the standards aren't quite here yet, it looks like they will be soon.

Because Web Services require multiple HTTP (request-response)s across the Internet, they are inherently 1000's of times slower than an API call on a local machine.

"Web services" don't require HTTP at all. And, since the obvious point of the whole exercise is to communicate with other systems on a network, pointing out that calls are slower than on a local machine is pointless. You know, web browsing to a machine across the Internet is also inherently 1000's of times slower than browsing on your own machine--yet seems to be popular. There are also techniques like WSIF for invoking web services where the client and the server could be on the same virtual machine, if appropriate.

Because the various implementations of SOAP (Web Service's underlying protocol) differ, clients and server on various vendors' machines will not currently interoperate.

I don't know much about this one either, but it doesn't make sense on the face of it. The whole idea of defining a common wire protocol like SOAP is for interoperability. Maybe it's true, but it seems like anyone who makes such an implementation is doomed to have their implementation sit unused. Of course, if you are Microsoft, you might be able to pull it off...

All this pales when one considers the effort involved in getting the IT groups of two cooperating corporations to agree on what a term such as "business partner" means and how it is to be represented in XML and/or a database.

I suppose this would have to happen in any integration effort of any kind, so it doesn't seem to be a convincing argument against "web services" (unless you are opposed to integration on general principles).

Today, remote procedure calls are used on the Internet, but not nearly as often as local procedure calls, and certainly not nearly as often as Web Services Proponents would have you believe. A world of Web Services would attempt to distribute processing across the internet, and would fail miserably. Contrary to the premises of the Web Services architecture, the only viable future architectures are those that integrate and centralize processing and that minimize remote procedure calls.

It seems like this is the same thing that web servers do today. However, instead of a human user sitting in front of a GUI initiating every request and consuming the data, "web services" let computer programs initiate the requests and consume the data. Why should this be intrinsically doomed to failure when done with "web services" in a computer program, when it seems to work pretty well for the human user of a web browser?

I dunno, just seems like the poster got up on the wrong side of the bed or something. I'm no "web services" zealot, but it seems like there is a lot more potential there than the poster thinks.

Then, I go to Outlook, or Outlook Express, or Netscape Communicator, or Mozilla, and I install the certificate. Then, I click the "Digitally sign this email" checkbox to automagically send my certificate to sign the email, and additionally click the "Encrypt this email" once I receive a certificate from an end-user to encrypt the email.

Sure, there are scalability issues, but any good PKI implementation can take care of those for corporate use. And, with a Network of Trust like Thawte is creating, you get the PGP-like ease-of-use with the PKI-class trust-level of a real PKI. All for the home user.

And no, I don't work for VeriSign or Thawte. I did work for a company that used certificates. A lot...

https://www.verisign.com/repository/cps20/cps20.pd f

Just post their email all over the place so they can get spammed into oblivion. Enough people do that and they may think twice. Yes, I have gotten the emails from Verisign too. Here's a good place to start.

That would be a spin.

Verisign the Registry has tried to cope with this situation. They have been working for the past 6 months to try to find a reasonable solution which provides equal access to all registrars. Unfortunately they have not been able to do that using purely technical means.

The agreement with the Department of Commerce states "NSI shall take all reasonable steps to ensure the continued operation, functionality, and accessibility of the Shared Registration System." Appearently this is the next reasonable step.

As I stated in my previous post there proposal may not be the best solution. However I think it is unfair to compare what they are doing with what occurred at that other registry.

Do it the same way it's done now.
You have big com's selling 'em (VeriSign for example)
and people giving them away for free.
thawte.
Thawte is great, it'll give you a DigitalID/Personal Certificate thing for free, but it comes with the name of "Thawte Free User".
You then earn "points", and when you have 50 (i think) you can have your name instead of "TFU".
You get points by going to see other members who have got over 100 points, and then show 'em your ID (passport/drivers lience/etc) and they award up 10 points.

This way you can have an "ignore free members" option aswell, insuring that all posters can be traced, or ignored.

Mike

No one makes money off of DNS . . .

These people disagree, but I think they help prove your point :)

assures that the organization exists, that the organization
has authorized the certificate, and that the person submitting the application
was authorized to do so.

As many slashdotters know, Verisign doesn't always follow through on that assurance. It would be nice if congress established a similar set of verification guidelines, and backed it up with legal force. Naturally, a certificate authority could be held liable if they claim to verify a signature without actually verifying it.

It would also be nice if an organization wishing to be a certificate authority, could get a license, and a name in the .sign.us domain.

Finally, it would be nice if certificate authorities were prohibited from disclosing any personal information (like IP numbers of people who checked a certain signiture) without a court order.

This is no longer the case. Microsoft has changed their policy on this for the time being. CAs pay nothing...

On the other hand, CAs must pass a WebTrust CA audit in order to get on the list. WebTrust audits are extremely expensive. Of course, they serve a useful purpose. They serve to give the end user some sense of confidence that the CA does due dilligence in determining that "you are who you say you are" before issuing a certificate. There is a very small group of companies that have passed WebTrust Audits... (according to WebTrust press releases, Verisign, Entrust, Digital Signature Trust).

Setting up a non-profit to issue certs sounds like a nice idea, but isn't a realistic option when one must spend lots of money to audit ones practices to assure the public. The commercial CAs are even having troubles making money...

Determining that "I am who I claim to be" really is a difficult task.

If you have your personal identity (ie. age) verified for a certificate and then use that certificate to sign your approval to access a site, that should be good enough.

Keep your certificate on a Smart Card, and it's portable, safe, and convenient.

I'm not talking about science fiction here. I'm talking about technology already being used all over the world for mostly security and corporate applications.

The only other thing I'd like to see is for the system to be more anonymous.

Hick town eh?

Oh yeah, way out there in Fairfax County.

Funny, we have the NRO, one of the largest airports in the US, an 802.11b wireless network, SGI, a linux users group, and an Intel datacenter, not to mention also having a boatload of linux careers. Oh yeah, and don't forget that MAE-East often gets cut by cows chewing on the fiber out here in hickville. Oh, I forgot some little things like ThinkGeek, NSI, and ARIN.
Oh yeah, and that hick high school is getting me my CCNA.

I'm not even going to mention AOL, Erols, or the CIA.

But you get the picture.

- Cary

DATELINE JULY 9, 2001

FOR IMMEDIATE RELEASE

Konqueror Embraces ActiveX, Plays Shockwave Movies

July 9, 2001 (The INTERNET). Nikolas Zimmermann and Malte Starostik today announced the availability of reaktivate for Konqueror, KDE's web browser. Reaktivate enables Konqueror to embed ActiveX controls, such as the popular Shockwave movies, for which no native Linux/Unix solution exists. Reaktivate relies on the WINE libraries to load and run ActiveX controls.

With this addition, Konqueror now enables KDE users to take optimal advantage of sophisticated websites that make use of Microsoft Internet Explorer plugins, Netscape Communicator plugins for Linux and Java applets, as well as KDE plugins designed using KDE's KParts technology.

According to Malte, the reason he and Nikolas implemented reaktivate is rather simple: it broadens the spectrum of web sites accessible to Konqueror, and it was possible.

Successes and Limitations

Theoretically, Reaktivate can eventually be used to embed any ActiveX control into Konqueror. Currently, however, not all ActiveX controls are compatible with reaktivate. In particular, the Microsoft Windows Media Player cannot be installed using reaktivate (though it is not known if a player which is already installed will work with reaktivate). Thus it is likely there exist other ActiveX controls which will not yet work with reaktivate. Work is ongoing to increase compatability with other ActiveX controls, including the Apple QuickTime plugin.

So far, however, reaktivate has been successfully tested with the following ActiveX controls:

Note on Security

Install ActiveX controls only from sites that you trust. Microsoft's ActiveX technology has often been criticized for weak security. Those controls are dynamic libraries that are executed exactly like any other piece of code installed on the user's system. This means they have full access to the file system, the system registry etc. As a means to establish the users' trust in the controls a web site wishes to install, every ActiveX control is cryptographically signed and carries a certificate issued by an authority known to the web browser (like VeriSign). A control that has no signature or no certificate or if they are invalid will not be installed.

With reaktivate the situation is similar: the installed controls can call every WinAPI function provided by the WINE libraries and therefore have access to WINE's registry and all files visible to the WINE installation. The current implementation of reaktivate will ask the user for confirmation to install a new control, but it will not check the embedded certificate and signature. This is due to technical reasons as well as limited time. Therefore we strongly advise to install controls only from sites that you trust. To save your files from malicious controls, you might also consider using this feature only from a seperate user account that has no access to your main user's files. Reaktivate will not run from the root account.

Source code for reaktivate is freely available under a Free, Open Source license from the kdenonbeta module in KDE's CVS repository and its mirrors. See the KDE website for information about how to get a module from CVS. You only need the toplevel, admin and reaktivate directories from kdenonbeta. Before compiling, get the latest CVS version of WINE (a snapshot will likely not be new enough). Next, apply all patches from reaktivate/patches-for-wine/ against the WINE sources and build/install WINE. Finally, you can build and install reaktivate.

Disclaimer: reaktivate is not in any manner sponsored or endorsed by, affiliated with, or otherwise related to, Microsoft Corporation.

Thanks to Andreas "Dre" Pour and Navindra Umanee for assisting in drafting this release.

ie. is it goatsex that is leading the way?
Or is it plain Jane erotica?
Or do people simply not care as long as it's free?

That's the kind of metrics I care about. Maybe we could loosen the religious right's hold on America if we could show that, indeed, most people in this country are depraved lunatics. After all we are a D E M O C R A C Y right?

Steven

Ok, so I suppose that now all of you are going to try to convince each other that you trusted Verisign in the first place, da? Like, you know, the same Verisign that owns NSI. Right. I'll go for that.

There are lots of Class 1 certs (search under Option 2 for Microsoft) issued under the OU 'Microsoft' that are obviously invalid. Class 1 certs are only email-verified, so, it's certainly a caveat emptor world with Class 1s...

Anyone have any lead on the certs we should be avoiding? Are they on their CRL (even though codesigning wisely (cough) doesn't check the CRL)?

This issue that I see is not that there is a technology issue at stake here. PKI, and Trusted Third Parties are only 20% technology. The other 80% (IMHO) is Process, Policy, Procedure etc.

What happened is the process broke down. Someone was able to impersonate Microsoft, and Verisign fell for it. What do you think the chances are that if the Verisign dude who issued the certificates followed the Certificate Policies, and Ceritificate Practice Statements (CP / CPS) that Verisign has spent mucho $$$ on, this would have happened?

I think pretty slim. Had the process been followed, no matter how good the impersonator was, someone would have caught it. Here is an extract from Verisign's CPS:

"Validation of Class 3 certificate applications for organizations includes review by the applicable Class 3 IA of authorization records provided by the applicant or third-party business databases, and independent call-backs ("out-of-band" communications) to the organization"

Obvisously this didn't happen, and thus we have untrusted certs roaming around.

As I post this, neither Verisign nor MS mentions this on their front page. Do they want to wait until the next cracker to deface the front page of Altavista or Yahoo adds an ActiveX virus and wipes out (quite easily) ten million machines?

http://www.verisign.com/repository/CPS/CPSCH2.HTM# _toc361806948

http://www.verisign.com/products/asb/faq.html

Especially interseting is the Assurance level that comes with this cert.

Even if these certiciates are never used, there will be some pretty heavy US govt. involvement as a result of this.

Anyone know if this has happened with any companies less visible than MS? A quick search did not turn anything up, but if Versign's procedures could let something like this slip through...

http://www.verisign.com/repository/CPS/CPSCH2.HTM# _toc361806948

http://www.verisign.com/products/asb/faq.html

Especially interseting is the Assurance level that comes with this cert.

Even if these certiciates are never used, there will be some pretty heavy US govt. involvement as a result of this.

Anyone know if this has happened with any companies less visible than MS? A quick search did not turn anything up, but if Versign's procedures could let something like this slip through...

Here's the Verisign Certification Practice Statement - from what little I read the person who fraudulently claimed to represent Msft might be in some serious trouble.

Versign has such a statement, which itemizes what they (in theory) do before issuing a cert.

-jbn

You'd go to Verisign for the same reason you'd sell your house through or real estate broker. The third party guarantees the transaction.

In most places, the real estate broker has some legal responsibility to make you whole if there are problems. More important, theroker's reputation is their most important asset.

If you pay them 5% of the sale price and the buyer trashes the house in the final inspection or skips town before the closing or whatever, the real estate broker is going to be inclined to fix things, even if it costs him money. --Just so he can keep collecting fees.

Verisign is the same way. More so since it is Lloyds of London that is actually paying the claim.

The original article says the price of a VeriSign SSL cert is $349 USD.

I think it should be noted that according to VeriSign pricing the $349 is only for a 40-bit cert. The 128-bit cert is now $895 USD.

Personally, I don't encrypt my email because I don't send anything sensitive. If I did though, the $14.95 wouldn't kill me (especially since my OS, browser, and all my apps are free).

Verisign charges a minimum of $350/year. That's right, you have to pay the Verisign Tax every year. Of course, if someone captures your cert, they can only impersonate you until it expires. Thawte (which has been bought by Verisign) still provides certs for $125/year, and that's what my site uses (I hope they don't raise the Thawte price, though I can't see why they wouldn't now that they've got a near monopoly). Netscape comes loaded with several others certification authority keys, but all of those folks seem to only offer certs in conjuction with their hosting or their (expensive) software.

SSL certs aren't cheap, because represent a significant effort to verify the business contact info for the operators of the site. For e-commerce, it's a really good idea, that little lock icon closing means two things... your data is encrypted, and the sight you're communicating with really is who they claim to be. The certification authority's process is thoughly audited by a big-five accounting firm (KPMG for Verisign, I think), and those folks ain't cheap (I know because Robin works for one of the big-five).

Getting a huge portion of the web to click the non-default choices to allow a untrustworthy certification authority would be a serious reduction in the overall security of e-commerce, and it's probably open a huge opportunity for spammers to appear as reputable business. Not a good idea.

If you want to fill the net with encrypted data, what's really needed is a protocol that doesn't require either side to incur a monetary cost. SSL is (or at least seems, not being an cryptanalyist) a good e-commerce protocol. SSL's barrier to entry and reoccuring cost will prevent if from being useful for the social goal of filling the net with encrypted streams.

Penguin better have my money! The Linux Pimp

Penguin better have my money! The Linux Pimp

Look for ENUM .. coming soon to a TLD domain monopoly near you ..

I recently installed Apache/mod_ssl at work and tried to use it with our existing Verisign certificate. Verisign has some weird double certificate system that caused connection errors with some builds of IE5 under mod_ssl. The same certificates worked under Apache/Stronghold. The mod_ssl FAQ has lots of information on connection problems with IE, but I tried every single suggestion and couldn't get it to work. I eventually switched to a Thawte certificate. That worked like a charm.

So - does anyone know if the problems I encountered were mod_ssl/verisign specific, or does Apache-SSL have the same issues?

Cheers.

VeriSign will assure you that the server you are securely connected to is who you think it is.

While it is possible and common for a http cache/proxy to "grab" all http connections without a normal user noticing, certificates prevent anyone anyone fiddling with a https connection without the browser warning the user.

Sun isn't interested in the hobbyist market.

They don't make money dealing in individual little-fish customers. When they talk about being "the dot in dot-com", they're not talking about pers ona l home page dot-com's. They're talking about businesses that make (want to make) money hands-over-fist on-line.

1. Consistency of server management procedures.

1. In-house tools (scripts) written for Solaris SPARC would run (mostly) unaltered on Solaris x86.

1. In-house applications (binaries) written for Solaris SPARC would run (mostly) unaltered on Solaris x86 after a quick recompile.

1. CDE/Motif (Yeah, large corporate organizations use it instead of GNOME or KDE. Live with it.)

1. Excellent support from Sun (as long as you pay the $upport Contract)

1. Entry-level Solaris-on-RaQ customers would eventually graduate to Solaris-on-SPARC

1. Revenue from support fees.

1. Larger installed based - bigger mind share.

1. Easier to manage support/service organization when dealing with one OS. A more controlled-development OS, for that matter.

When your $5,000-per-hour revenue stream stops because of a subtle server problem at 3am, do you think a linux support organization is going to call the author of the broken code and make him fix the problem? You are mistaken.

<shameless plug>
I'm in the process of setting up on-line ordering on my website right now. Most of the website is technical resources for building electronic projects using embedded processors. A recent addition, that we expect to need the on-line ordering for, is the open source MP3 player, which today is a primitive first generation design, but hopefully soon I'll have a nicely redesigned version.
</shameless plug>

Fortunately, my partner is an accountant, which has really helped. She set up a proper visa merchant account with our bank. It cost $100 up front. They take $0.65 per sale, plus approx 3%. There's a minimum $15 monthly charge, so hopefully we'll actually sell at least $500/month. The visa charges are entered using a touch-tone phone, so we didn't have to buy any equipment. They offer a terminal, for (I think) $450. With the terminal, we would get a per-sale charge of $0.07, and a little lower percentage of the sale, about 2.5% as I recall. They let you buy and add the terminal anytime you want.

It looks like there's a free software package called CCVS - Credit Card Verification System which allows your linux (or unix) box to emulate a terminal (requires a dedicated modem)... but there's a catch. It needs to be loaded with an encryption key. Redhat sells these keys for approx $1000. If anyone knows someone who can provide a key for CCVS for less, please contact me. Robin found a similar windoze based program, where they wanted a monthly charge and some percentage of the sale, on top of the percentage taken by the bank! Not cool, but I wouldn't run a windows server even if it was affordable.

Setting up the SSL stuff on the webserver is relatively easy, but you need a cert. VeriSign charges $350, so we went with Thawte, who only wanted $125 (even though they're now owned by Verisign). Again, robin did most of the work there. I generated the CSR from the server software, and she faxed them copies of our LLC papers and other business stuff. About a week later we got the cert. The cert lasts for only one year, you it looks like we have to pay $125 every year. I hope they don't jack their price up to Verisign's level!

Robin ran a test charge onto her credit card a couple days ago, and it seems to be working very nicely. The merchant appears as "PJRC.COM, LLC", which I think is much cooler than "ibill...some number".

For the on-line shopping cart, I looked at a couple of them, but they didn't have that look and feel that I want for my website, so I've been rolling my own. It's turned out to be a bit more coding than I originally thought, but still not too bad, and I'm really happy with the results. When the order is confirmed, the code just sends Robin and I an email, and makes sure the data stored in our database really matches what they filled out on the form.

I'm putting the final finishing touches on the cgi scripts right now, and hopefully it'll be on-line later tonight!

"Recently, VeriSign, the Apache Server Project, and SSLeay have collaborated to allow anyone running an Apache server to secure their site with the strongest encryption available"

You know I own VRSN and as an investment this could be a good thing for the company... get that PE out of the 8k range (scary even for the new ecom)...
As a user this scares the hell out of me. You want to talk about 500 pound gorrilas, this merger will make one. VRSN owns somthing like 90% (it could be less I could be wrong but it is still high) of the security certificates out there. I can only wonder what they are going to do with all that info(al la doubble click any one). Another post sugested a one stop shop for a secure domain name, and guess what it is alredy there. No more fuss muss and hassle... The thing that I find intersesting is that your site gets netsure protection, up to 250k of it. I wonder how or who is providing that insurance? I though that deploying and insuring a product was illegal, again I could be wrong. But the conditions (link follows) of this plan override any other terms and agreements that you may have...
http://www.verisign.com/repo sitory/netsure/netsure2.html
read it youll want to cry or laugh