Interview with Sameer Parekh

Jim Dennis, ``The Answer Guy'' columnist for Linux Gazette, recently interviewed Sameer Parekh for Linux Journal. Sameer Parekh is the founder of C2Net Software Inc., http://www.c2.net/, the company that imports the Stronghold web server. Mr. Parekh has been active on the Internet since 1990, especially in areas related to privacy, electronic civil liberties, security and cryptography. Stronghold has added fully licensed commercial SSL support and other features to the popular Apache web server. Excerpts of Jim's interview are printed here; the full interview will be in the August 1 issue of Linux Gazette, http://www.ssc.com/lg/.

Jim: What can you tell me about C2Net as an organization? I know it used to be Community Connexions.

Sameer: Yes, we started out as an Internet provider and a privacy provider--protecting people's privacy on the Net. People could get anonymous accounts and set up anonymous web pages. We were strong supporters of the re-mailer network; we set up the means by which people can browse the net anonymously through our proxy. That business was going reasonably well. I was running it pretty much as a hobby in my spare time, while still a student at Berkeley. Then, I left school to start contracting at SGI down in the South Bay (the southern end of the San Francisco Bay area--near ``silicon valley''.

At the end of last year we came out with Stronghold, though it wasn't called that at first. It was called ``Apache-SSL U.S.'' and started going really well. It became clear that we'd do a lot better selling cryptography products rather than privacy services. So, we moved our focus away from privacy services and changed our name to c2.net to reflect that change in focus and to concentrate primarily on deploying strong cryptography worldwide. As of a few months back, we officially had the name changed to C2Net Software Inc.

Jim: And you moved your customers over to Dave Sharnoff's idiom.com?

Sameer: We moved our dial-up customers over to idiom some time ago--around April, 1996. We were still supporting the privacy services until late last year, when we moved all our web hosting and anonymous account holders to Cyberpass, a company in San Diego. Cyberpass is run by a cypherpunk (a mailing list for the discussiong of the politics, technologies and social ramifications of cryptography and privacy issues) who is very active in privacy and in the re-mailer network.

Jim: You just mentioned the ``cypherpunks''--you and I met at one of their meetings on the Stanford University campus in Palo Alto. Do you find most of your employees from this group?

Sameer: I find most of my employees from that group. The others I find from people I know from school, from other personal contacts and from existing employee referrals. Of the eleven employees I have, I met about half through cypherpunks.

I think a lot of my stand on privacy is related to my involvement with the cypherpunks and to my involvement in the controversy surrounding the clipper chip when it was first proposed.

We're the only company willing to deal with the fact that what the US government is trying to do with their export restrictions goes beyond just impeding or restricting export--it is creating a chilling effect so that companies inside the US would cripple their cryptography even for their domestic products. All of our development happens overseas so that we can do cryptography worldwide, and so that the international versions of our products will not have to be crippled to 40-bit keys that can be broken in three and a half hours.

Jim: So your approach is similar to the one John Gilmore and Hugh Daniels are using with the Free S/WAN project--keeping the developers at the other end, while you're providing the quality assurance on this side.

Sameer: Well, actually, we're providing mostly the marketing and the sales. We do a little bit of QA, but that's too close to the export issue. We also do the documentation--that's all written in the U.S. Also, all the protocols and the standardization efforts take place in the U.S. Stronghold conforms to protocols developed and published by Netscape, the W3 consortium and the IETF--among others.

Jim: Now, there's something I'm curious about. You've combined Apache and SSLeay, Eric A. Young's SSL (secure sockets layer) implementation, and integrated them into Stronghold. Then, you got a license from RSA so that you could include their public key libraries. How did you approach the Apache organization with the idea for a commercial version of their free package?

Sameer: Well, Apache is free under the Berkeley-style license, as opposed to the GPL, which means that I didn't have to have any connection to the Apache group. Apache's license allows you, so long as you insert the appropriate copyright notices, to start selling an Apache-based product without other delays.

But that would be kind of rude, I think. I'd been involved in the group before having any intention of changing the focus of my business. I saw a need for an SSL version of Apache that could be available within the U.S., so I started working on it and found SSLeay and Ben Laurie's Apache-SSL patches, which he'd done in the UK. I integrated these for limited distribution within the U.S.

I already knew many of the Bay Area members socially. I became a contributor to the Apache group--although not as big as the people who do large chunks of the code--I do testing and help with the documentation. A full-time tech writer employed at C2Net does documentation which she contributes back to the Apache group.

Our product is doing well, so our connection to the Apache group has been mutually beneficial. Any bug reports we get from our customers go back to them; any bugs we find, we fix and donate back. A large number of the features we've added, we've also donated back. Naturally, we haven't donated all of our added features, since we need to maintain some proprietary value so that we can make some money, as well.

Jim: What do you think about the GPL versus Berkeley issue? I know this is an ongoing bone of contention between the FreeBSD and Linux camps.

Sameer: I'm generally in favor of Berkeley over GPL because I think free software is best done in a variety of different contexts. In particular, with the crypto environment, it's impossible to do completely free software inside the U.S. if it involves any public key techniques, because of the patents. RSA holds a suite of patents which cover almost all known forms of public key encryption--patents are quite different from copyrights in that a re-implementation of the same algorithm is still covered.

I think the fewer the restrictions we place on our software, the more people will use it.

Jim: How many international programmers do you have and where are they located?

Sameer: We have two, and we don't say where they are. We don't want the U.S. government to know which country they're in, or they might pressure those countries to add export restrictions to their laws.

The NSA (National Security Agency) has appointed a person, David Aaron, whose sole job is to convince other countries to adopt restrictions similar to ours--so that our strategy won't continue to work. Obviously, if all other countries had similar export restrictions, doing development in any given one would allow sales only in that locale. That would be pointless in a global economy. We want to ensure that the country where we are doing our development will not be targeted.

Jim: Have you or any other company had any official contact with the NSA?

Sameer: I haven't, but I've heard a lot of rumors from companies who've had visits from them and were told, ``What you're doing is wrong; you should stop it or it will do bad things to the rest of your business.'' NSA can't do that to me because I have no other business. We do cryptography, and we're at odds with export restrictions on intellectual property.

Jim: Would you see that as your edge against Microsoft, Netscape and Sun--that they would have other aspects of their business that might get severely hampered by the fight against cryptography export restrictions?

Sameer: Well, it's not worth it to them. It doesn't make good business sense for them. At the same time, it is a business necessity for us.

Any company who doesn't want to fight this battle can let us have that chore. They (and their offshore distribution agents) can license our software, and they won't have to do any development. They won't have to put their business at risk over questions of cryptography technologies.

Jim: How many platforms have you ported Stronghold to?

Sameer: Stronghold supports almost 20 different forms of Unix, including Linux. It supports both the ELF and the a.out libraries. It works with versions 1.2 and 2.0, although we recommend using the latest stable kernel.

Jim: Which implementation do you think is your biggest volume seller? They're all priced the same, right?

Sameer: Yes, they're all priced the same. Linux is our number one seller--next to it, we have Solaris and Irix. I haven't actually done the numbers because we don't sell on a ``per-platform basis''. We sell a Stronghold license, and the buyer can use it on whatever platform he wishes.

Jim: Now you have separate numbers for evaluation copies acquired and for copies licensed. About how many evaluation copies are being downloaded every month?

Sameer: On the order of 20 to 30 a day, which would come to about a couple hundred per week, or about 1,000 per month.

Netcraft shows that we have an installed base of about 20,000 on the public Internet, but that includes the virtual hosts, so it's not 20,000 actual hosts--it's the number of domains served by a Stronghold server. It's sort of a misleading number because they're checking only the non-SSL sites, and a lot of people run Apache on their unencrypted server and Stronghold on the encrypted server. Many run Stronghold on both, as well.

Netcraft did a different survey of SSL servers where we came in second. That is, for servers in general, we came out second among commercial Unix servers and fourth in commercial overall.

Jim: The Netcraft surveys you've been referring to, is there a link to them somewhere on your web pages?

Sameer: Well, it's at www.netcraft.com. I think the surveys are on our site as well. I'm proud of our Netcraft ratings, so we mention them prominently.

Jim: What other products are you working on?

Sameer: We have our ``Safe Passage'' web proxy. This does full-strength SSL for web browsers worldwide. It's currently in beta and is available at our U.K. site. It provides a locally-hosted proxy to provide full-strength cryptographic capabilities to the international versions of Netscape and Microsoft browsers. As you know, these are limited to 40-bit crypto when sold outside the U.S.--denying them access to sites requiring the stronger keys domestically available.

Basically, ``Safe Passage'' allows a user's browser to talk 40 bit to the proxy on his system which, in turn, talks to hosts out on the Web. Currently, it runs only under Windows.

Jim: What do you think of the Free S/WAN project?

S/WAN is a ``secure wide-area networking'' protocol from RSA--Free S/WAN is a work in progress which is being imported by another group of cypherpunks and John Gilmore of the EFF.

Sameer: I think it's a good thing. We need to provide IP level encryption in addition to the applications-specific security provided by programs like Stronghold or PGP. With regard to our product line, we haven't evaluated how that might fit into our strategy, so I don't have any comment from a business perspective.

However, from a more personal point of view, I think producing a freely available implementation of IP level encryption is a great thing. We want this deployed so that all of the Internet traffic is encrypted and, thus, authenticated.

Jim: Getting back to Stronghold as a ``commercially supported Apache Server'' and leaving aside its support for SSL and commerce... are there any companies offering just that--just a commercially packaged Apache?

Sameer: There are companies that offer Apache support services--but there aren't any selling a supported package--where you'd get a shrink-wrapped box, with binaries and pre-printed documentation, so these companies just offer the service. We offer a product--which includes e-mail support, of course.

Cygnus was doing some Apache support as well, but I believe they may have dropped that. Then there was a company in South Africa, Thawte, which had a product called Sioux. We ended up buying that one out and integrating its features with Stronghold's.

Sioux was released a few months after we had produced ``Apache SSL U.S.'' We started talking to Thawte--and decided to buy Sioux from them to eliminate any conflict of interest for some other business we wanted to do with them. You see, Thawte's primary business is as a CA (certification authority). It was an amicable arrangement, since Sioux wasn't the kind of software business they wanted to get into. We are now bundling Thawte certificates in the Stronghold package for only $50 US more--which is about half the regular price of a Thawte.

Jim: I've been reading in the Apache's modules lists about phps; what are they?

Sameer: php originally stood for ``Personal Home Page''--but it doesn't mean that any more, so it's just php and doesn't stand for anything.

A php is a specific module that does dynamic content--a phrase I like to use for things like server side includes, extended ssi, php, e-perl, etc. They are all providing dynamic content--where the page is parsed by the server and the data which are sent to the client are based on the scripting inside the original document.

We like php because it's easy to use, it's very robust and it offers connectivity to almost every database out there. Well, I shouldn't say that--there are a lot of databases ``out there''. It can connect to Postgres '95, mSQL, Solid, Sybase, ODBC, etc.

It's a way to embed scripting inside your HTML. For example, you can have conditional sections that include blocks of HTML based on the results of certain pieces of code. You can have an HTML page that does a database query, formats and sends information out of the database. php offers significant speed advantages over CGI since it's loaded directly into the web server. You save the load of forking off a Perl process, which you must do when using CGI.

Stronghold 2.0 bundles with the php module--2.0 is in beta now. We've been using php quite a bit in-house for our database connectivity and our external web site.

We also support the server side includes--which were in the early CERN server. Stronghold is based on Apache, which also includes the ``extended SSI''. XSSI adds things like conditionals.

Jim: Do you think tools such as these are better than CGI?

Sameer: Yes, it's a lot easier to build applications--particularly where it's not a complicated application--where you just want to include a little scripting directly in your HTML. If you use a CGI script, the script has to output all of the HTML. It's just as transparent to the browser--but it's a lot faster, and it's a lot easier for the web administrator to maintain.

Jim: Currently, the whole SSL view of the world, brought to us by the Netscape Commerce Server, is all about the server authenticating itself to the client--about web sites saying ``You've reached me--and not some imposter and there's no man-in-the-middle and we can exchange information privately''. This approach doesn't seem to offer anything other than manually typed passwords. Maybe we need some sort of client authentication certificates for SSL.

Sameer: Actually, that's already in there. Stronghold already supports client authentication. The SSL protocol added that in version 2. Netscape supports client certificate authentication starting with Navigator version 3, which was built around the same time as SSL version 3.

Stronghold was the first widely-used commercial server to support SSL client authentication. Now that we have the support in the browser and our server, it's only a question of user acceptance and getting sites to start using it.

The SSL client authentication is an excellent technology. We're using it extensively here at C2Net. Because we have people from all over the world, we can't have this big private WAN, and we can't set up a VPN6 using something like Free S/WAN--it isn't ready yet.

Jim: Do you see C2Net coming out with, maybe, an ssltelnet and sslftp to compete with ssh?

Sameer: Well, we can't talk about all the details of all our product ideas. Actually, ssltelnet and sslftp already exist--no one's supporting them, and no one's using them yet.

I think for encrypting secure shell logins and file transfers, ssh is the best product out there. Although it's a different authentication protocol, unlike the SSL between my browser and my web server--it is RSA-based, and I can use my copy of ssh through my Ricochet and log in to my servers.

Jim: What else can you think of that just has to be said?

Sameer: The key thing that we at C2Net are focusing on is the worldwide deployment of cryptography. I think it's vital that we deploy strong crypto worldwide in the very near future.

The U.S. government has made it clear that their intent is to make the personal use of strong cryptography completely illegal. Deployment has to happen before they do that. If these crypto products aren't ubiquitous before then, we'll have a much harder time protecting our privacy.

I see cryptography being used for much more interesting things than just protecting credit cards. While it's prudent to encrypt your credit card number before sending it over the Net, it's not an interesting application of strong cryptography.

We want to build an infrastructure so that restrictions on personal use of privacy technology will have major business implications ... so that privacy itself cannot be made illegal.

Jim Dennis is the proprietor of Starshine Technical Services (http://www.starshine.org). His professional experience includes work in technical support, quality assurance and information services for both large and small software companies. He has just begun collaborating on the 2nd Edition of a book on Unix Systems Administration. Jim is an avid science fiction fan. He can be reached via e-mail at info@mail.starshine.org.