Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
All of my Favorite K5 People

By imrdkl in Technology
Fri Jun 14, 2002 at 10:17:20 AM EST
Tags: Focus On... (all tags)
Focus On...

Are to be found on this webpage..

What? You say you can't get in? That's because the page is secured with SSL which requires you, the client, to have a client certificate to access it. Read on to find out how to get one.

This is the final segment of my widely criticised and generally boring Introduction to Digital Certificates. Previously, in parts 1 and 2 of this series, I discussed the some of the high-level activities which are authorized in digital certificates. Namely - Client, Server, and Codesigning authority. As mentioned, these three types of secure activities are based on authority which is "built-in" to the certificate itself in the form of attributes (fields), and extensions. In this article we'll take a look at a real example of each of these types of certificates, and introduce the "low-level" attributes which are necessary to construct each type.


To set the stage, assume there exists a webpage which tells us who are the most important people on this website. This page, however, is considered by the owner to be private information. To access it he demands that you have a digital client certificate. You would then need to request one from a CA which is trusted by both you and the owner of the "Most Important People Page". We've agreed that the Roadkill CA, is ok as the trusted third party, and now we've sent in the certreqs, as discussed in the previous article. The good people at Roadkill CA have approved the requests, and signed them, creating three new certificates. Now these certificates have been returned to us, for our own use.

Before we have a look at our new "certs", some overview with linkage is in order. Digital certificates have an important history, and have a lot of hardworking people making them better.

Digital certificates are based upon a standard called X.509. This standard, with three major revisions so far, specifies how a certificate shall be built. Certificates which are created via the first version of the specification (v1), are generically used, often as self-signed server certificates. The typical mod_ssl installation will create a v1 certificate for the Apache Server using openssl, so that the server can be started and run in SSL-mode while waiting for a certificate from a major provider, or as an experimental/demo/internal server. (As a k5 reader, you might recall that when text ads were introduced, rusty created a self-signed certificate to manage the paypal stuff. That certificate was a v1 certificate.)

With the third revision of the X.509 spec, called x509v3, a certificate can be specified and created with more details about exactly what it should be used for. X509v3 specifies extensions, which themselves specify additional details about the certificate's usage, and owner. Extensions define, at a more granular level than was possible with previous versions of the x.509 specification, the type of authority that a certificate is granted to perform secure activities on a machine or device which requires trust.

The rest of this article will focus on examples based upon the x509v3.

Certificate Construction

The extensions which are encoded within a v3 digital certificate were originally defined within RFC 2459, which was written in 1999. Ongoing work regarding certificate extensions is defined, codified, and approved (via open and standard internet process) by the PKIX. The PKIX is the organization which generally works on the definition and specifications of X.509 PKI.

Note - Netscape also had an early certificate specification which is still supported in certain software implementations, but I will not discuss that specification further due to length considerations

Rather than consider the exhaustive list of all extensions which are defined by PKIX and the various RFCs, it's appropriate to again limit our focus to the the types of certificates which are needed to build an Web-PKI. These types have been mentioned before, and are likely the type or types of certificates that you have already seen and approved for activities on your own machine, if you use the internet for your personal or professional business already.

Let's start by by analyzing an end-user server certificate. This is type of certificate that might be issued to you as the administrator of of a private/internal business website. Alternatively, as a secure website user, you have acknowledged and accepted one or more of this type of certificates to deliver your secure information across the internet. Before looking at the guts of this type of certificate, you can download the complete Server certificate, if you wish. You'll notice that the previous link includes the certificate itself, in a pure text format which looks like this:

-----BEGIN CERTIFICATE-----
MIIEUjCCA/ygAwIBAgIBATANBgkqhkiG9w0BAQQFADCBuDELMAkGA1UEBhMCTk8x ETAPBgNVBAgTCEFueXN0YXRlMRQwEgYDVQQHEwsxMjMgNHRoIFN0LjEUMBIGA1UE ChMLUm9hZGtpbGwgQ0ExITAfBgNVBAsTGEVsZWN0cm9uaWMgVG93bmUgQ291bmNp bDEbMBkGA1UEAxMSUm9hZGtpbGwgQ2xpZW50IENBMSowKAYJKoZIhvcNAQkBFhtp bXJka2xAaW1yZGtsLmhvbWVsaW51eC5jb20wHhcNMDIwNjEyMTE1OTQ2WhcNMDIw OTEwMTE1OTQ2WjCBtzELMAkGA1UEBhMCTk8xETAPBgNVBAgTCEFueXN0YXRlMR0w GwYDVQQHExRBbnkgVmFsaWQgQWRkcmVzcyBPSzEUMBIGA1UEChMLUm9hZGtpbGwg Q0ExJzAlBgNVBAsTHkt1cm81aGluIERpZ2l0YWwgSWRlbnRpdHkgRGVtbzEWMBQG A1UEAxMNSzUgR3Vlc3QgVXNlcjEfMB0GCSqGSIb3DQEJARYQd2ptQG1ldHJvbmV0 LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDNWUfyki7icDuV966S5x+wexpK F72LLMfNjjisgfLKsRH8u387fHrnYHRb9/XUMMzeZCiangBVamVbGJzd/XytAgMB AAGjggHuMIIB6jAJBgNVHRMEAjAAMAsGA1UdDwQEAwIGwDATBgNVHSUEDDAKBggr BgEFBQcDAjAbBgNVHREEFDASgRB3am1AbWV0cm9uZXQuY29tMEoGA1UdHwRDMEEw P6A9oDuGOWh0dHA6Ly9pbXJka2wuaG9tZWxpbnV4LmNvbS9jYS9yZXZva2VkLmNn aS9DQS9DbGllbnQvY3JsPzCCAVAGA1UdIASCAUcwggFDMIIBPwYEKgSGCTCCATUw PAYIKwYBBQUHAgEWMGh0dHA6Ly9pbXJka2wuaG9tZWxpbnV4LmNvbS9jYS9wb2xp Y3kvaW5kZXguaHRtbDCB9AYIKwYBBQUHAgIwgecwEhYLUm9hZGtpbGwgQ0EwAwIB ARqB0FRoZSBSb2Fka2lsbCBDZXJ0aWZpY2F0aW9uIFByYWN0aWNlIFN0YXRlbWVu dCwgaHR0cDovL2ltcmRrbC5ob21lbGludXguY29tL2NhL3BvbGljeS9pbmRleC5o dG1sLCBnb3Zlcm5zIHVzZSBvZiB0aGlzIGNlcnRpZmljYXRlLiAgVGhpcyBlbmQt dXNlciBjZXJ0aWZpY2F0ZSBpcyBpbnRlbmRlZCBhbmQgYWxsb3dlZCBmb3IgdXNl IG9ubHkgYXMgYW4gZXhhbXBsZS4wDQYJKoZIhvcNAQEEBQADQQBvAAdBLOxtfVHH K2DvdHgvOVC1TDhNGSTk7e51WEyHkhoSaeC/6kUNihVt1X55RBfd7NMp5xCP8jaA
AtB3YI/B
-----END CERTIFICATE-----

Of course, the text form doesn't really help much to understand what the certificate looks like. In actuality, a certificate is constructed as a formal data structure in a binary form, and populated with the data from the certreq, discussed previously, and the signing key from the CA. It's this binary form that is stored in the device or process which uses it to communicate securely. The text form above is simply a way to transmit a certificate.

Also included in the link above, is the "text-dump" of the properties which are contained within the certificate. By analyzing the text dump, we can learn everything we want to know about the certificate.

Analysis of an End-User Server Certificate

  • Version - indicates that this is a X509v3 certificate
  • Serial Number - indicates that this is the first end-user certificate issued by the CA, although serial numbers may not always be ordered in this way. Each individual CA may use its own. In the various documents I read to researching this article, the PKIX does not supply guidelines regarding serial numbering, except perhaps that the serial number be unique within its parent authority.
  • Signature Algorithm - the signing key pair for this certificate is based on RSA, using MD5 hashing. (Saying more than that about this element is fodder for a complete article, and well beyond the scope and interest level of this practical intro.)
  • Issuer (DN) - The DN for the CA which issued this certificate. In this case, with the CN=Roadkill Server CA. (The structure and functionality of the CA and Root is covered later)
  • Validity - the certificate expires 90 days after it was issued. This also happens to be the lifetime (expiry) of the parent CA.
  • Subject (DN) - this is the all-important Subject DN, which is built in the process of making the certificate request. By convention, the CN component of the DN in a server certificate should always contain the valid DNS name of the server which it certifies, although there exists no convention in client software as to the action taken if the CN does not contain the proper hostname.
  • Subject Public Key Info - the Subject key pair for this certificate is based on an 512 bit RSA public key.
  • X509v3 extensions - here's where the real strength of v3 certificates is found. Some of them, such as basic constraints, are standard for end-user certificates. The most interesting extensions are related to key usage. The Extended Key Usage extension specifically says what this certificate was intended for, namely, server authentication. Each of the values in the key usage class are directly passed in from the signing (CA) certificate, and therefore the Roadkill Server CA must also contain the same key usage capabilities which it passes in. In the case of the Roadkill Server CA, these were also inherited from a parent, the Roadkill Root CA. The Roadkill CA is a multi-tiered CA, and will be the topic of my next article in this section.
  • Signature Algorithm - this identifies the algorithm used by the CA to sign the certificate. Again, saying more than that is beyond the scope of this article.
X509v3 Client Certificate Fields and Extensions

The Client certificate for our demonstration has its own distinct list of fields and extensions. Some of the fields are the same as for the server certificate, however. This client certificate contains the same sort of features as one that you might get from your bank, for example, to access your account online.

The OU in the this certificate's DN is customized, to allow someone (you) to gain access as a "guest". Distributing this sort of a "bootstrapping" certificate allows the server to run exclusively in a stricter mode of SSL that requires client certificates for all access.

This certificate is also signed by a different intermediete CA. The Roadkill Client CA is a CA which signs client certificates only, based upon specific authority granted to it from the Root. Again, the Extended Key Usage specifies what the intent of the certificate is, and note that instead of Key Encipherment as a Key Usage value, the client certificate has a different value called Non-Repudiation. Non-Repudiation is a difficult concept to define, but in the context of a client certificate, it essentially tries to guarantee the operator of the server to which you are connecting, using the certificate, that you will pay your bills. That's just one possible definition of Non-Repudiation. There are others, as we'll see for Codesigning certificates, for example. The definition of Non-Repudiation in fact continues to be a widely debated topic, and that's probably a good thing. In any case, as already stated, a proper examination of the meaning of key usage attributes is fodder for a complete article.

Finally, take careful note of the Subject public Key. You'll be referring back to it after you look at the Codesigning certificate next.

X509v3 Codesigning Certificate Fields and Extensions

The codesigning certificate is the last one we'll be looking at. This is the type of certificate which might be issued to a company, or an individual developer, for signing code which is deployed as part of a web application.

Again, the codesigning certificate is signed by a Intermediete CA beneath the Roadkill Root CA, this time it's the Roadkill Codesigning CA, and again the subject CN is specifying the entity for which the certificate is designated, the demo user or developer. As well, the Extended Key Usage again specifies the actual intent for the certificate, and again the certificate requires the Non Repudiation value. In this case, however, the non-repudiation is assigned to the distributor/server of the web application, instead of the user/client of the web. In this way, Codesigning certificates are also like Server certificates, in that they authenticate and "guarantee" the web owner. You may have run signed code (DLLs, Shockwave, Java, etc) on your machine in the past, after being prompted whether to accept (trust) the certificate which signed the software, and its CA.

Especially interesting in this case is the public key for the subject. Note how it is exactly the same public key that is used by the Client certificate. Both certificates were created with the same key pair. This is a common scenario, for example, in a development environment where a developer must have a codesigning certificate as well as his standard web-client certificate. Using the same keys to create multiple certificates is a convenient option, but may or may not be available to you for a given CA. However, if you create your own CA, then you, and the other members of your CA can make your own policies.

Summary - What have we learned in this boring-assed series?

This series of articles has introduced the basic concepts and mechanics of digital certificates, with an eye towards implementing a simple Web PKI. There are many other purposes for which X.509 certificates can be used, of course, but the three which comprise a Web PKI, Client, Server, and Code Signing, do bundle together quite nicely, and provide a working example of a commonly-implemented type of CA. This series only touched upon the subject of certificate key pairs, signature algorithms, and ciphers. Again, these topics call for an extended analysis which is beyond the scope of an introduction, and is largely independent of X.509 certificates themselves. Another thing that has only been touched-on in this series is CA certificates. Our focus has been primarily limited to so-called end-user certificates, the kind that the average reader might be obtaining.

Ideally, the reader does have a better idea now, of what certificates are, how to get one, and how they're built. There's really no magic, or dark mystery in this topic - anyone who uses a certificate, regardless of the purpose/activities for which they are using it, should have some basic familiarity with them. There is a tremendous amount of hype and "salesmanship" available on the web, regarding certificates and PKI implementations which come from one provider or another. Additionally, there are many so-called "gurus" out there who love to scream "dont trust them!", when talking about PKI and X.509, the inference being that there must be a hole in the implementation somewhere, and when it is found, your identity will be comprimised and sold (cheap) all around the world.

To all of this hype and naysaying, I politely say, bunk. Certificates and PKI should not be expensive, and neither are they the answer to all of lifes problems. What they do provide is an level of security in your electronic transactions which exceeds that which you'll find with simple passwords or password calculators, and especially cookies, which all too many sites still use. The US government, for example, has begun to adopt X.509 PKI in a big way. Several large organizations within the Department of Defense, have converted major systems over to PKI-based access and single-sign-on with certificates, including the Central Contract Registration (PDF) system. The DoD has had other successes, along with other governmental departments in the Federal government, which I'll review in an upcoming article. The point is that PKI is coming, whether you like it or not, or trust it.

Of course, there's plenty of other warts to point out with PKI based on X.509, as well. Applications which use certificates still have no uniform standard with how to treat a certificate which is suspicious, for example. Some refuse to do anything, others present dialogs which try to give fair warning, but miss the mark in describing the nature of the certificate anomaly.

Hopefully, comments below will also point out other potential flaws. Neither do I claim to be any sort of expert in the field, albeit I do find myself in the role of a limited advocate for the technology. Consider as well, that once the Department of Defense is sold on a concept, there's going to be a lot of money made by the people who can develop and implement it best. I can recall turning up my nose at other technologies that have come along, only to find my nose slightly out of joint when salaries for delivering the technology went through the ceiling a few years ago.

Perhaps the industry is a bit more sensible regarding salaries these days, but security must take a bigger role, as we all know, and X.509 looks to be the way it is going, although other implementations are to be found.

Coming up next - Simple Web PKI

My next article in this section, will delve alot deeper into the CA certificates which form the basis of the Roadkill CA, and begin to introduce how they might be used as the foundation for a web PKI, as promised. In an attempt to catch your interest with this article, I've also tantalized you with the possibility of access to a little page that will tell you if you are among the most important people on this site. Imrdkl's Ark, if I may be so bold. You may have tried to access it above, but found that you couldn't get in. If you really think you're ready to come on board, then go here first, and then come aboard again.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
The DI section? (unofficial)
o more! 32%
o bah. 30%
o Dump it, rusty. Find some other way to feed your damn cats. 37%

Votes: 59
Results | Other Polls

Related Links
o on this webpage.
o 1
o 2
o mod_ssl
o text ads
o RFC 2459
o PKIX
o early certificate specification
o complete Server certificate
o text dump
o making the certificate request
o Client certificate
o codesignin g certificate
o Central Contract Registration (PDF)
o are to be found
o go here first
o come aboard again
o Also by imrdkl


Display: Sort:
All of my Favorite K5 People | 31 comments (16 topical, 15 editorial, 0 hidden)
I got in! (5.00 / 2) (#5)
by Stereo on Thu Jun 13, 2002 at 08:51:21 PM EST

Here's a mirror :)
hi

kuro5hin - Artes technicae et humaniores, a fossis


is that it? (none / 0) (#6)
by tps12 on Thu Jun 13, 2002 at 09:00:34 PM EST

My vote depends upon your answer, I won't tell you how.

[ Parent ]
Is it really important? (4.00 / 1) (#10)
by Stereo on Thu Jun 13, 2002 at 10:21:50 PM EST

He changed it now anyway, go check it out :p

kuro5hin - Artes technicae et humaniores, a fossis


[ Parent ]
Yes, slightly modified (none / 0) (#27)
by imrdkl on Fri Jun 14, 2002 at 03:24:49 PM EST

I forgot to say who you are, what you're doing, who you're doing it with, and how.

That part works now, and I've pushed the changes to production.

[ Parent ]

diabolicly genius (4.00 / 1) (#9)
by nodsmasher on Thu Jun 13, 2002 at 09:23:35 PM EST

in an anoying sort of way
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Most people don't realise just how funny cannibalism can actually be.
-Tatarigami
ARG!!!!!!!!!!!!!!!!!!! (none / 0) (#30)
by sweetie on Sun Jun 16, 2002 at 01:32:10 AM EST


"If god thinks he's doing me wrong , he'll strike his ass down with a lightning bolt!"
Have you been fucked with the wrong way? If so then post that Bitch or Dick to my Dick
[ Parent ]
Hmmm... (4.50 / 4) (#19)
by Obvious Pseudonym on Fri Jun 14, 2002 at 05:50:15 AM EST

What? You say you can't get in? That's because the page is secured with SSL which requires you, the client, to have a client certificate to access it. Read on to find out how to get one.

A much more likely scenario is that people will react to this the way I did...

I can't get in because I need to have a client certificate - well sod that then I won't even bother to click the link.

We've agreed that the Roadkill CA, is ok as the trusted third party, and now we've sent in the certreqs, as discussed in the previous article. The good people at Roadkill CA have approved the requests, and signed them, creating three new certificates. Now these certificates have been returned to us, for our own use.

Sorry, but I haven't agreed that they are trusted.

The problem you have with Digital Identity is that the thing you are restricting access to must be tantalising enough to overcome both people's apathy and their paranoia. As far as I know there is nothing on the Internet that good as far as I am concerned - and based on this sample size I would naturally assume that anything new that is offered is also not going to be worth it unless provided with solid evidence.

After all, I use a free ISP (using a fake name and address) and there are lots of anonymous/free sites out there. So far, nothing on the Internet has been worth paying for individually - either in cold, hard cash or accurate personal details...

Obvious Pseudonym

I am obviously right, and as you disagree with me, then logically you must be wrong.

Keep in mind (5.00 / 2) (#22)
by imrdkl on Fri Jun 14, 2002 at 07:58:16 AM EST

this is an example. Whether or not you decide to try it is less important than the fact that you've considered it. In any case, there are a lot of people trying it, and succeeding in getting access to the protected page. For many of them, I suspect, it is the first time that they've considered certificate management, or used the certificate manager tools on their own machine.

If you decide not to trust the Roadkill CA, that's ok, as long as you realize that your browser software comes pre-installed with many certificates which are trusted by default, without you ever having a say in the matter.

My articles in this section do not slight anonymity as a liberty, as a protection, or as a tool. I only seek to show that the technology can work, where it is desired. Furthermore, as evidenced by the homegrown nature of the Roadkill CA, it should be obvious that a CA is available to anyone, and not just for those willing to pay big money.

Finally, the example itself demonstrates security beyond simple server-based SSL, in that a client cannot connect at all, unless they have a certificate. This can reduce brute-force attacks on a login page, for example, because getting to the page is much more difficult.

Whether you use the internet to pay for transactions or not, is of course your own business.

[ Parent ]

Which is what is intended (5.00 / 2) (#26)
by jolly st nick on Fri Jun 14, 2002 at 09:22:48 AM EST

A much more likely scenario is that people will react to this the way I did...

I can't get in because I need to have a client certificate - well sod that then I won't even bother to click the link.

Which is exactly the point. If you set up an example like this, you want 99.9% of the people to go away. Examples: I'm putting my company's secret business plan on the web for the senior managers to review; I'm posting my decrypted "Harry Potter" DVDs for my friends to share. In these cases, I give you a certificate so you can read the data; everyone else (competitors, MPAA) can just move along.

[ Parent ]

The article was fine... (5.00 / 1) (#20)
by dipipanone on Fri Jun 14, 2002 at 07:37:46 AM EST

But God alone knows why you think highly of that witless bastard...

--
Suck my .sig
I agree wholeheartedly. (5.00 / 1) (#31)
by loucura on Mon Jun 17, 2002 at 07:48:16 PM EST

You are either lying, or blatantly trolling when you say that he is one of your favourite people of k5.

[ Parent ]
I must be doing something wrong (none / 0) (#21)
by Ubiq on Fri Jun 14, 2002 at 07:41:39 AM EST

since my galeon won't eat your certificate. It asks for a password, I enter a blank one. It says "Failed to restore the PKCS #12 file for unknown reasons." Hmpfrt.



The password is not blank (none / 0) (#23)
by imrdkl on Fri Jun 14, 2002 at 08:12:43 AM EST

See the installation page again. In any case, it works ok with my (and other) galeon browsers. My version is 1.2.0.

[ Parent ]
woops. (none / 0) (#25)
by Ubiq on Fri Jun 14, 2002 at 08:54:03 AM EST

Missed that one. However, with the non-blank password it gives me the same error.



[ Parent ]
Client authentication (4.00 / 1) (#28)
by iggie on Fri Jun 14, 2002 at 04:39:40 PM EST

I've played around with certificates to do what you've done here: Client authentication as opposed to server authentication which is done in e-commerce. My frustration came down to MSIE's dealing with self-signed server certs, and self-signed X509 client certs. Basically it either didn't work (still doesn't on Macs), or it worked poorly, or it was a pain. Netscape (as old as 4.x) worked seamlessly - it guided the user through a set of dialogs to establish a self-signed server cert., and a server-issued X509. No files to download, preference panels to dig around in, etc. Probably Microsoft was like that because SSL was an invention of Netscape, and it got too big thanks to e-commerce to be embraced and extended. At least they could kill client authentication, which I believe they successfully did. I gave up on this mechanism basically because even though I didn't use MSIE, most other people did, and I would have had to tell them to use Netscape only. Doubtless many others came to the same conclusion as well. That's why you now log into your bank account without a client certificate, but with a password only. Hard to imagine how much more secure our personal information would be now if it weren't for this needless posturing.
I'm about to revisit this issue, and although I haven't personally tried it, I assume that this works acceptably enough in MSIE in Windows. Most Mac users are only glad not to have to use MSIE, so hopefully that won't be a problem.
Incidentally, your certs only worked with Mozilla on my OS X system, and only after much screwing around. Why do this through this file, instead of just starting with an SSL connection and going through the dialogs necessary to verify RoadKill, then accept the RoadKill-signed X509? Don't tell me you have to do it this way just to accommodate MSIE...
On OS X, browsers that didn't work include Chimera (Gecko based, though in V0.3b now), OmniWeb (no certificate preferences to speak of), and of course MSIE, which still doesn't allow you to do anything with certificates other than delete them.
Thanks for the article, though. It prompted me to set up my own self-signed server cert on my OS X box (which was QED, by the way). Pointing Mozilla at local host walked me through a set of dialogs to establishing my self-signed cert to be a trusted cert. I guess I'll belly up to one of the NT boxes here and see what MSIE does with it.

pkcs12 format (none / 0) (#29)
by imrdkl on Fri Jun 14, 2002 at 05:48:15 PM EST

works ok pretty much everywhere, nowadays. MS2k needs some nudging to import, but MSIE > 5.01 is pretty seamless, except for the Root installation dialog defaulting to NO (as it should). But older MS4 had troubles, yes.

The pkcs12 format was also necessary because it's the only way I know of to deliver working certificates, of which the Guest Certificate is.

Generally, as you point out, it's easier to let the browser do the installations implicitly, but the Roadkill CA is 3-tiered, which makes auto-installation more complex. Self-signed v1 certs don't install in root. Typically a tiered CA is delivered in p7 CRL format (without the CRL).

It's good to see my article has generated a bit of interest. Watch this space for more facinating insights. :)

[ Parent ]

All of my Favorite K5 People | 31 comments (16 topical, 15 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!