remote pool_handle_t
[tlspool] / README
diff --git a/README b/README
index cc2b869..529387e 100644 (file)
--- a/README
+++ b/README
@@ -1,7 +1,7 @@
 TLSPOOL README
 ==============
 
-The tlspool package concentrates TLS-use by client and server applications.
+The tlspool package concentrates TLS usage by client and server applications.
 It gets passed a file descriptor of a socket, initiates TLS over it, and
 then makes a callback with authenticated local/remote identities in a
 request for an additional file descriptor for the plaintext side.  This
@@ -46,7 +46,7 @@ The core logic used here is (client shown, server is similar):
                        close (plainfd);
                        plainfd = -1;
                }
-               ...error reoprting...
+               ...error reporting...
        } else {
                ...continue to use plainfd...
        }
@@ -65,8 +65,8 @@ in the tlsparams structure after this call.
 The importance of PKCS #11
 --------------------------
 
-The key material used by this daemon will be accessed over PKCS #11.  This
-requires multi-layered attacks to key material: the material is protected
+The key material used by this daemon will be accessed over PKCS #11.  Compromise
+will require multi-layered attacks to key material: the material is protected
 by a secure key store of choice, in hardware or software, and even the PIN
 for using the private keys without seeing them is stored in a separate
 program, namely the TLS Pool.  Specifically, the PIN and key material are
@@ -94,7 +94,7 @@ for usable keys to authenticate its identities to the Internet, both over
 X.509 and over OpenPGP.
 
 One final, and hardly recognised use of having a central TLS Pool and
-potentially centralised PKCS #11 repositories is the ability to sniff
+potentially centralised PKCS #11 repositories is the ability to monitor
 the network traffic for intrusion attempts.  To be able to do this in
 the presence of encrypted connections, the ability to decrypt the
 traffic must be offered to sniffers like Snort.  The decryption usually
@@ -185,64 +185,6 @@ For each of these, information is collected to support accounting:
   - a final count representing the number of items being accounted.
 
 
-
-Build targets
--------------
-
-  - src/tlspool is a daemon that provides the centralised STARTTLS service.
-  - lib/libtlspool.so / .a provide a stub library for applications.
-  - tool/testsrv is a test server using immediate STARTTLS on incoming TCP.
-  - tool/testcli is a test client using immediate STARTTLS on outgoing TCP.
-  - tool/tlstunnel is an instant wrapper using STARTTLS after optional CHAT.
-
-
-Tests / demonstrations
-----------------------
-
-A simple test can be run on one system (testcli and testsrv connect on
-localhost port 12345) to setup a line-based chat system between client and
-server.  Note that the server will only respond to one client at a time; it
-is a mere test program that wants to show the chat on the server console.
-
-    tty0# cd src ; ./tlspool -kc ../etc/tlspool.conf
-    tty1$ ../tool/testsrv
-    > Hello
-    < Oh, hi
-    ^D
-    tty2$ ../tool/testcli
-    < Hello
-    > Oh, hi
-    ^D
-
-**Note:** The `cd src` is done to ensure that the default database references
-in `../etc/tlspool.conf` can point to `../testdata/*` files.  In an installed
-version, the configuration file would hold absolute path names and there
-would be no reason to be in any particular directory.
-
-A more lively demonstration is the tlstunnel tool, which connects an address
-and port in plaintext to an address and port in TLS-encrypted ciphertext.
-It can even perform a simple CHAT interaction to bootstrap a textual sequence
-to negotiate protocol-specific STARTTLS.
-
-    tty0# cd src ; ./tlspool -kc ../etc/tlspool.conf
-    tty1$ ../tool/tlstunnel -s -l [::1]:22335 -L testsrv@tlspool.arpa2.lab -r [2001:db8::80]:80
-    tty2$ ../tool/tlstunnel -c -l [::1]:22334 -L testcli@tlspool.arpa2.lab -r [::1]:22335 -R testsrv@tlspool.arpa2.lab
-    tty3$ nc ::1 22334
-    GET / HTTP/1.0
-    Host: demo.web
-
-    HTTP/1.0 200 OK
-    ...
-
-Note that this starts two tunnels; one is the server, marked with the `-s`
-option, translating TLS-wrapped content to plaintext, connected to the
-backend server (fill in your own address, for instance a web server);
-the second is the client, marked with the `-c` option, translating plaintext
-to TLS-wrapped content; the `nc` command connects to the client, which in
-turn connects over TLS to the server, which in turn connects in plaintext
-to the (web) server.  You can now manually run a web query in `nc`.
-
-
 Windows Porting
 ---------------