KLone2 HTTP S Features

babongo edited this page Sep 11, 2012 · 1 revision

The aim of this howto is to simulate a scenario in which a given web service is offered on a public internet/intranet to a close PKIX community via HTTP/S. We’ll see how to setup the whole PKI environment and have the klone web server to interact with the users’ community. What this environ specifically maps to, is up to your imagination.

CA and players' certificates setup

First of all we need to setup a CA to issue certificates for the players. You have to decide a suitable value for test_dir then we can begin creating the self signed CA certificate plus the CA file system hierarchy the OpenSSL way (using openssl version 0.9.8):

$ export test_dir="/my/test/dir"
$ mkdir -p ${test_dir}/CA && cd ${test_dir}/CA
[$ locate CA.pl => (e.g.) /usr/lib/ssl/misc/CA.pl]
[$ locate openssl.cnf => (e.g.) /usr/lib/ssl/misc/openssl.cnf]
$ cp /path/to/CA.pl /path/to/openssl.cnf .

You can customize openssl.cnf as you like, or just stick to defaults since it really doesn’t matter here. Anyway:

$ export SSLEAY_CONFIG="-config ${test_dir}/CA/openssl.cnf"
$ perl CA.pl -newca

Now create a certificate for the klone server, as common name use the web server uri, e.g. https://localhost:4443:

$ perl CA.pl -newreq
$ perl CA.pl -sign

Play some tricks onto the generated credentials’ files: we want to obtain a single file ws-creds.pem holding both certificate and unlocked private key:

$ mv newcert.pem ws-creds.pem
$ openssl rsa -in newkey.pem >> ws-creds.pem

Clean up a bit ...

$ rm -f new{key,req}.pem

OK, ready to get a certificate for the web client/browser which we’ll call wc1-creds.pem:

$ perl CA.pl -newreq
$ perl CA.pl -sign
$ mv newcert.pem wc1-creds.pem
$ openssl rsa -in newkey.pem >> wc1-creds.pem
$ rm -f new{key,req}.pem

If you want to create a PKCS#12 bundle instead of separate key and certificate credentials - say, in order to have it installed in your browser - after the -sign operation do:

$ perl CA.pl -pkcs12
$ mv newcert.p12 wc1-creds.p12
$ rm -f new{cert,key,req}.pem

KLone 2 Setup and Configuration

For the purpose of testing HTTP/S features we won’t use the “embedded” facilities that klone offers; instead we’ll use klone as a conventional web server whose configuration and resources to be served are located on the host file system. This fact implies that we can operate slight changes to the configuration (in order to test different HTTP/S features) without the need to go through the normal “embedded” deploy cycle. Keep in mind, however, that this is done only for the ease of test and that all the features highlighted are also available in the embedded context.

First of all download and compile klone (we need just the core package):

$ cd /tmp && wget http://www.koanlogic.com/klone/klone-core-x.y.z.tar.bz2
$ tar jxvf klone-core-x.y.z.tar.bz2 && cd klone-core-x.y.z/
$ ./configure --enable_sup_fs --enable_debug --disable_cxx --install_daemon_only --prefix=${test_dir}
$ make
$ make install

You have now your https server binary installed at ${test_dir}/sbin/kloned.

Create some very interesting content to be served to your clients:

$ mkdir ${test_dir}/www && cd ${test_dir}/www
$ cat << EOF > index.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <title>KLone HTTP/S test page</title>
  Hello HTTP/S world!

Now create an etc directory and place the kloned configuration file in it:

$ mkdir ${test_dir}/etc/ && cd ${test_dir}/etc/ 
$ cat << EOF > kloned.conf
server_list     my_https

    type syslog
    syslog.facility     LOG_LOCAL0

    type            https
    addr.type       IPv4
    addr.port       4443
    dir_root        ${test_dir}/www

    ca_file         ${test_dir}/CA/demoCA/cacert.pem
    cert_file       ${test_dir}/CA/ws-creds.pem
    verify_client   no

OK, we’re ready to fire kloned at last:

$ ${test_dir}/sbin/kloned -dFf ${test_dir}/etc/kloned.conf

Testing with an HTTP/S Client

Now that the server is up we can focus on the client side of the game. We could use a common browser with HTTP/S capabilities (e.g. Mozilla, Safari, Explorer) but we prefer to have full control over the testing scenario so we are going to use the openssl s_client. Anyway you can try the same with your preferred browser if you feel more confortable, just remember to set it up correctly (i.e. TODO create the PKCS#12 file). Let’s open another shell and do:

$ export test_dir="/my/test/dir"
$ openssl s_client -connect localhost:4443

Your client has established a TLS channel with klone which can be used to exchange HTTP data, e.g.:

GET /index.html HTTP/1.1

should give you back the index.html page that we’ve created earlier.

Now we’re going to stress the client a bit. Change verify_client from no to require in kloned.conf; stop & restart kloned and retry with:

$ openssl s_client -connect localhost:4443 

It should fail. That’s because server explicitly asks for client certificate and client can’t provide it: this results in handshake failure.

OK, then try to tell kloned who you are by feeding s_client with your credentials:

$ openssl s_client -connect localhost:4443 -cert ${test_dir}/CA/wc1-creds.pem

It works!

We are now in a situation in which the client (potentially any number of them) and the server are mutually authenticated and have a private, secure channel on which they can exchange sensible data.

Handling Client Revocation

Suppose that at a certain point in time your credentials are revoked by the CA:

$ cd ${test_dir}/CA
$ openssl ca -revoke demoCA/newcerts/<serial>.pem
$ openssl ca -gencrl -out ca-crl.pem

Then add the following line in the my_https section of kloned.conf file:

crl_file        ${test_dir}/CA/ca-crl.pem

Stop and restart kloned:

$ openssl s_client -connect localhost:4443 -cert ${test_dir}/CA/wc1-creds.pem

failes with reason code “certificate revoked” or similar...

That’s all for now.