Jim Dennis, "The Answer Guy" columnist for Linux Gazette interviewed Sameer Parekh for us. Sameer Parekh is the founder of C2Net Software Inc., http://www.c2.net, the company that imports the Stronghold web server. Stronghold has added fully licensed commercial SSL support and other features to the popular Apache web server.
Jim: So how many platforms have you ported Stronghold to?
Sameer: We support almost 20 different forms of Unix.
Jim: Obviously Linux is one of them. Do you require a 2.x kernel?
Sameer: No. We support both the ELF and the a.out libraries. It works with 1.2 and 2.0, although we generally recommend using the latest stable kernel.
Jim: Which version, or implementation, do you think is your biggest volume seller? They're all priced the same right?
Sameer: Yeah, they're all priced the same. I think actually Linux is our number one seller. Then, second to that, we have Solaris and Irix. I haven't ... I really should do the numbers. I haven't done those because we don't sell on a "per platform basis." We just sell a Stronghold license, and they can use it on whatever platform they like.
Jim: Now you've got separate numbers for when people have gotten a evaluation copy and when they've licensed it. About how many evaluation copies are being downloaded every month?
Sameer: I couldn't tell you precise numbers ...
Jim: Just a ball park... are we talking about 100 per week, a 1000 per week ...
Sameer: On the order of 20 to 30 a day so that would come about to a couple hundred per week or about 1000 per month.
Netcraft shows that we have an installed base of about 20,000 on the public Internet. But that includes the virtual hosts as well so it's not 20,000 actual hosts, it's the number of domains served by a Stronghold server. It's a sort of deceiving number because they're only checking 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.
Obviously since we have 20,000 unencrypted sites but there's probably a higher number of people running Stronghold just on the encrypting port of their site.
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 that you've been referring to, is there a link to those 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 pretty proud of our Netcraft ratings so we mention that pretty prominently.
Jim: What can you tell me about C2Net as an organization? I know you used to be Community Connexions ...
Sameer: Yes, we started as an Internet provider, and a privacy provider -- protecting people's privacy on the Net. People could get anonymous accounts, they could set up anonymous web pages. We were strong supporters of the re-mailer network, we set up the anonymizer which lets people browse the net anonymously through our proxy.
That was going reasonably O.K. I was running it more as a hobby in my spare time while I was a student at Berkeley. Then I left school to start contracting at SGI down in the South Bay1.
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 that started going really well. It became clear that we'd do a lot better selling cryptography products then w'd do at selling privacy services.
The privacy services was going O.K. but it wasn't enough to become a day job... it wasn't enough to get an office... it wasn't enough to hire people... it was pretty much a one man operation out of my house when it was just a privacy business.
So, as it was obvious that we could do a lot better by selling and deploying cryptography, we moved our focus away from the privacy services and changed our name to c2.net to reflect that change in focus and to concentrate primarily on deploying strong cryptography worldwide. So, 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 back, some time ago like, last April or so--but we were still supporting the privacy services until late last year when we move all of our web hosting and anonymous account holders to Cyberpass which is down in San Diego and is run by a cypherpunk2 who is very active in privacy and in the re-mailer network.
Jim: You mentioned that you do cryptography as your business and you just mentioned the "cypherpunks" which is where you and I first met--probably at one of the meetings on the Stanford Campus in Palo Alto. It that where you find most of your employees?
Sameer: I get most of my employees from there and from people I know at school and through other personal contacts and existing employee referrals. So I think that, of the eleven employees I have, about half of those I know through cypherpunks. We a pretty cypherpunks oriented company.
We're really the only company that's 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--but to create a chilling effect so that companies inside the US cripple their cryptography even for their domestic products. So we're one of the few, maybe the only company in the U.S., that's standing up to this ... that isn't willing to back down in the face of this chilling effect.
I think a lot of my motivation is related to my involvement with the cypherpunks and being involved during all the controversy surrounding the clipper chip when that was first proposed.
All of our development happens overseas so that we can do cryptography worldwide and the international versions of our products don't 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 what Jon Gilmore and Hugh Daniels are doing with the Free S/WAN project--keeping the developers on the other end and you're providing the quality assurance on this side...
Sameer: Well, we're providing mostly the marketing, actually, 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.
The main benefit of having a U.S. office is the marketing and sales even though all of the development has to happen overseas, all the protocols and the standardization efforts, all that new stuff is all 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 which is Eric A. Young's SSL3 implementation--and those are what you've integrated in Stronghold. Then you got a license from RSA so you could include their public key libraries. So how did you approach the Apache organization with the idea for a commercial version of their free package? What kinds of licensing...
Sameer: Well, Apache is free under the Berkeley style license as opposed to the GPL which means that, if I wanted to, I didn't have to have any relationship with the Apache group. It's possible to just take Apache and, according to their license, leave in the appropriate copyright notices and just start selling a product.
But that would be kind of rude I think. I'd been involved in the group already before having any intention of changing the focus of my business. I saw a need for an SSL version of Apache that would be available within the U.S. So I started working on it and found SSLeay and I found Ben Laurie's Apache-SSL patches, which he'd done in the UK, and I integrated all of that for limited distribution within the U.S.
So I had joined the Apache group for that. I already new many of the Bay Area members socially. I became a contributor--though not as big as the people who do large chunks of the code but I do testing and help with the documentation. I have a tech writer who's a full-time employee of C2Net who does documentation that she contributes back to the Apache group.
I originally joined in an effort to support the group because I think that free software is a great thing. As the product has started doing well I think that 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* the features since we need to maintain some proprietary value because we need to make some money as well.
Jim: Did you talk to Eric Young?
Sameer: Yes. We're in close contact with Eric. We work really well with him.
Jim: I'm not familiar with his licensing...
Sameer: Yes, both his and Ben Laurie's are very Berkeley style licenses. They are free software for commercial and non-commercial use--you just have to give credit. So in our marketing materials, documentation, and on our web pages it says "this product contains software written by Eric Young, and by the Apache Group" ... that sort of thing.
Jim: So what do you think about the GPL vs. 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 that 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 involve any public key techniques, because of the patents4.
So for doing crypto inside the U.S., because of the intellectual property issues and the patent environment, it's impossible to release products under GPL. I think that the fewer restrictions we place on our software the more people will use it.
The reason I would write free software is so that people will use it. If you put complex restrictions on your software saying that you can't sell any derivatives of it unless.... you create a lot of worry.
Perhaps the motivations of the people writing GPL software are not just to make it widely used. That's valid. But it doesn't match my personal motivations for releasing free software. It's clear that it should be properly credited and have some controls. I don't think things should be released to the public domain.
Well, I do see a lot of debate about that question--particularly on the FreeBSD mailing list. I suspect the debate and flame wars on that will go on forever.
Jim: So, how many people have you got working here?
Sameer: We have nine people here in the U.S. and two people abroad and then we have a couple of contractors. That comes out to about 14 or so.
Jim: And where are your international programmers?
Sameer: We don't say. We don't want the U.S. government and others to know which country they're in. They might then put pressure on that country to add export restrictions to their laws.
This administration has appointed a person, David Aaron, whose sole job is to convince other countries to adopt similar restrictions to ours--so that our strategy won't continue to work. Obviously if all other countries had similar export restrictions than doing development in any given one would only allow sales in that locale. That would be pointless in a global economy.
So they have this guy, David Aaron, who effectively harasses and bullies other countries into adopting restrictions for US interests. We want to ensure that he can't target the country where we are doing our development.
Jim: And no one from our government's asked? Have you had any official contact yet?
Sameer: No. Not yet.
Jim: Do you know of other companies that have?
Sameer: I've heard a lot of rumors from companies who've had visits from the NSA saying "what you're doing is wrong, you should stop it or it will do bad things to the rest of your business."
They 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: So, 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. So any company that doesn't want to fight this battle can offload that onto us. They can license our software--and their offshore distribution agents can also license our software and they don't have to do any development. They don't have to put their business at risk over questions of cryptography technologies.
Jim: I see. Speaking of other cryptographers, I hear that Phil Zimmerman just moved to the Bay Area to found PGP Inc. Do you have any contact with him?
Sameer: No. We don't currently have any professional contact with them.
Jim: I'm confused about what happened there. Phil licensed the commercial rights to PGP to a company called ViaCrypt ...
Sameer: ... then he bought ViaCrypt--actually their parent company.
Jim: That's what I thought I'd read. So what other products are you working on?
Sameer: Well we have our "Safe Passage" web proxy. This does full strength SSL for web browsers world wide. It's currently in beta and is available at our U.K. site.
That provides a locally hosted proxy to provide full strength cryptographic capabilities to the international versions of Netscape and Microsoft browsers. As you know those are limited to 40-bit crypto when sold outside of the U.S.--denying them access to sites that require the domestically available stronger keys.
Basically Safe Passage allows a user's browser to talk 40 bit to the proxy on their system which, in turn talks to hosts out on the web. It runs under Windows.
Jim: So what do you think of the Free S/WAN project5
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 regards 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 I think, from a more personal point of view, that 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 especially so it's authenticated.
Jim: Getting back to Stronghold as a "commercially supported Apache Server" and leaving aside it's 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 that sell a supported package--where you'd get a shrink-wrapped box, with binaries, and pre-printed documentation, or anything like that. 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 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 that product from them to eliminate any conflict of interest for some other business that we wanted to do with them.
You see Thawte's primary business is as a CA (certification authority). So it was an amicable arrangement since it wasn't the software business that they wanted to get into.
So we are now bundling Thawte certificates with a Stronghold package. That's only fifty dollars more--which is about half the regular price of a Thawte.
Jim: So do you find that many of your customers have to go with Verisign6 for other reasons?
Sameer: Well, Thawte is gaining in popularity though their certificates are only accepted in the latest browsers from Netscape and Microsoft. So support for older versions of Netscape is probably the main reason people had been choosing Verisign over Thawte. As the PKI certification7 authority marketplace matures I hope that people will be able to choose their CA's based on reputation rather than being stuck with whatever the browser makers supported.
Right now all of the CA's are too new to have any reputations. So far Verisign is known to be well funded and Thawte is thought of as a very small company. As far as I can tell they don't have any reputation with respect to which is more reliable.
The market will have to mature, and they will each have to have time to build up a track record before people will be able to make informed decisions.
Jim: Now, back when we were talking about support you mentioned that the e-mail support is included with Stronghold and that telephone support unbundled from it. What kind of support call volumes are you getting? Are you getting a lot of calls?
Sameer: Not at all. We have an installed base of something like 20,000 according to Netcraft--and we only about three people doing support and...
... there's no person who just does support. We're a small company so everyone does a lot of different things. But we have three people who mostly do support and two people with the word "support" in their title.
So the support load isn't very high. I think that's because the product is actually very easy to use, it's intuitive and it's easy to install.
Although we sold some phone support we really prefer e-mail. People get answers that are more fully formulated and they don't have to wait on hold. Also when we use e-mail then everything is tracked and recorded so it's easy to look back on what's been tried and it's easy to forward the issue around as needed.
We've been pretty successful steering people toward e-mail support so they don't have to buy the phone support.
Jim: So I've been reading in the apache's modules lists about these php's, what are those?
Sameer: php originally stood for "Personal Home Page"--but it doesn't really mean that any more, so it's just php and doesn't really stand for anything.
php is a specific module with does dynamic content--which is the phrase I like to use for things like server side includes, and extended ssi, php, e-perl and all of these things. They are all providing dynamic content--where the page is parsed by the server and the data that's sent to the client is based on the scripting that's inside the original document.
php is what we like to use because it's easy to use, it's very robust and it offers connectivity to almost every database out there. well I should say that--there are a lot of databases "out there". It can connect to postgres '95, msql, solid, sybase, odbc, c, etc.
It's a way to embed scripting inside of your html. So, for example, you can have conditional sections what will include blocks of html based on the results of certain pieces of code. You can have an HTML page which does a database query and formats and sends information out of the database. If 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 like you'd usually get with CGI.
So Stronghold 2.0 bundles with the php module. That's in beta now. We've been using php quite a bit in house for out database connectivity and our external web site. It's very useful.
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: So you think these sorts of tools are better than CGI?
Sameer: Yeah. 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: On a different tack, you've got a proxying client that brings international versions of the standard browsers up to domestic standards of cryptographic strength. that puts you pretty close to the browsers. Where do you see the browser market going? In the browser wars what would you like to see come out of it?
Sameer: Hmm. That's tough to say. I think there's no alternatives to the Netscape and Microsoft browsers at this point. It's hard to say if one will destroy the other. It's such an open subject, maybe you could be a bit more specific?
Jim: Well--do you see Java doing anything significant
Sameer: I think Java has some potential for distributed computing. it has a long way to go. it's rather unfortunate Microsoft has decided to create it's own proprietary version of Java.
Then there's javascript--which isn't Java at all. So Netscape's decision to rename live script to "java"-script and that's added confusion to an already confused marketplace.
I think javascript is interesting because there are a lot of potential security problems in it's design. Some versions of Java have implementation problems. Those can be fixed. The design of Java pays due care to security considerations.
However when a language like javascript is designed with out any security in mind--you can't fix it.
Jim: In other words "implementations can't fix fundamental design flaws."
Sameer: So the danger is that it [javascript] has a similar name [to Java]-- and it is useful for building Intranet applications where hostile applications are not a security concern. So javascript can be used to connect to internal HR data applications or to an order entry system and make the interaction a lot easier.
Javascript's features allow you to make your client more active--so the user doesn't have to send everything to the server to get feedback from your web forms.
The problem is that there is currently no provision to restrict the browser--to say "I'll accept javascript from within my network but not anything from anywhere else" or "I'm willing to accept javascript from these people but not them."
Once it gets to that point I think javascript will have more of a future and offer real benefits.
Jim: Could you add those features to your client side proxy--the filtering that is?
Sameer: It could be done. It would be a lot of work and I'm not sure there'd be enough of a market for it. I think it's best done in the browser.
Hopefully Netscape will add that to their features set soon.
I usually have Javascript disable--but I see some cases where I'd like to use it. If I could just turn it on for those applications it would be very nice.
Java is much closer to secure deployment and authentication.
Jim: Speaking of authentication--I have a question about SSL. 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 doesn't seem to offer anything for the client to authenticate itself to the server other than manually typed passwords. So maybe that's a feature that we'd like to see in the browsers--is 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 is built about SSL version 3.
Stronghold was the first widely used, commercial server to support SSL client authentication. So 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.
I think that the SSL client auth. is an excellent technology. We're using it extensively here at C2Net. Because we have people from all over the world we can't really have this big private WAN and we can't set up a VPN8 using something like Free S/WAN--because it isn't even ready yet.
So we issue client certificates to all of our employees. We have a Stronghold web server where our sensitive information is stored and an employee can connect to that server from wherever they are on the Internet and access business information. They are protected by full-strength cryptography and RSA encryption on the client side.
It's an incredibly empowering technology because we don't have to worry about making people come into the office to get this information. they can do it from home and the can do it securely.
Jim: So you don't have to worry about static IP addresses, and boring holes in your firewall and packet sniffers on your ISP's routers, and ....
Sameer: Right. As long as they have their client certificate on their laptop. You know I have a ricochet [ed. note: Metricom Ricochet are wireless modems that are popular in the Bay Area because they offer flat rate unlimited wireless PPP to modem users]--and I can do anything from my laptop through that.
I can review support questions, work in the bug tracking database, I use SSL to do logins. That isn't a product of ours.
Jim: I met Tatu Ylongen, author of ssh, at the IETF a couple of months ago. He's started his own company, too. I guess he does all the development and has Data Fellows doing all of the licensing.
Sameer: That's right. Data Fellows is doing all of the sales and marketing while he's doing the development.
Jim: So do you see C2Net coming out with, maybe, an ssltelnet and sslftp to compete with ssh?
Sameer: Well, we can talk about all the details of all our product ideas. there already is an ssltelnet and sslftp. nobody's supporting them and nobody's using them yet.
So I think, that as far as encrypting, secure shell logins and file transfers ssh is the best product out there. Although it's a different authentication protocol, not like the SSL between my browser and my web server--but it is RSA based and I can use my copy of ssh through my ricochet and login to my servers here.
Jim: So, if you were to configure all your systems here--presumably all Unix boxes, and you took out all of the unencrypted and weakly authenticated services you could almost run without any packet filters or firewalls--except to prevent address spoofing.
Sameer: We have packet filters on all the non-encrypted services--because there are still a number of useful services for use just within the private network. We don't allow any non-encrypted packets to pass through.
We allow ssh for logins and SSL for employee access to our internal web servers. Those both offer strong authentication--and the SSL is only accessible to people who have a C2Net employee certificate installed on their system.
Jim: Does the Netscape navigator support a "pass phrase" to unlock the locally installed certificates, like PGP does with your signature keys?
Sameer: Yes, it has some system where you use a pass phrase to encrypt your private keys.
Jim: So if you lose a laptop you don't have to run right into the office to revoke those certificates. Hopefully their crypto on that is strong enough to give you a few hours.
Sameer: I'm not sure what they use. Safe Passage uses DES [ed. note DES= Data Encryption Standard] You see browsers that support client certificates have to do RSA key generation. So the international versions are limited to 512 bits for the key. That means that Safe Passage has to proxy the support for the SSL client authentication as well. That puts the international client on an even footing with any of the domestic browsers since Safe Passage is actually connecting to the web servers for the browsers.
Another benefit of using Safe Passage is that it provides an integrated location for all your certificate keys if your using different browsers.
One of the problems with client certificates right now is that Netscape and Microsoft don't have a published interface for managing the keys that are installed in each. In other words if you've have a certificate in Navigator you can't transfer it to your copy of Internet Explorer and if you have a Navigator SMIME9 you can't transfer it into Eudora.
So Safe Passage helps by allowing you to use just one certificate database. We plan to offer an easy way to extract those certificates -- though we haven't figured out quite what that will be, yet.
There are standards emerging on how to do this--and we will be supporting those standards, of course.
Jim: Now this proxy is only available for Win 95, and NT
Sameer: ... and Win 3.1
Jim: Are you planning on release a Unix/Linux version of that
Sameer: Making it available for Unix wouldn't be difficult. It was actually prototyped under Unix and then ported to Windows and there a graphical interface was added to it.
However, there isn't much of a market demand, and we are a small company, so we can't afford to support Unix and Mac on it for now. We'll need to get some more resources before we could broaden that support--as much as I'd like to do it.
Jim: So, 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. So, the deployment has to happen before they do that. If these crypto products aren't ubiquitous before that we'll have a have a much harder time in protecting our privacy.
I see cryptography being used for much more interesting things than just protecting credit cards. While I think that it's prudent to encrypt your credit card number before sending it over the 'net--it's not an interesting application of strong cryptography.
So 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.