forked from arpa2/tlspool
-
Notifications
You must be signed in to change notification settings - Fork 0
/
INSTALL
254 lines (193 loc) · 10.4 KB
/
INSTALL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
INSTALLING TLSPOOL
==================
This explains how to install the TLS pool daemon, and how to play with the
test/demo programs for the client and server side.
Dependencies
------------
Runtime dependencies are:
* libgnutls >= 3.4.4 for TLS handling (that implies libnettle-2.7)
* p11-kit >= 0.22.1 for PKCS #11 URI handling
* libdb >= 4.0 for key->value lookup with BerkeleyDB transactions/replication
* libtasn1 for parsing of BER and DER data structures
* NOT-YET: libldns for DNS lookups
* NOT-YET: libldap for LDAP lookups
* NOT-YET: libmemcached for caching of intermediate results
* NOT-YET: libradius to do additional authn / authz [/acct]
* the PKCS #11 implementation of your choice (for easy entrance: softhsm)
Include the development variants if your aim is to build your own TLS Pool.
TODO: We should probably consider build variations to avoid requiring all
these dependencies when only a bit is kwown to be required. That's the
sort of maturity that this project has not reached yet.
First-time build
----------------
Create a user and group "tlspool" if you wish to drop privileges to a
separate account.
Use the common building approach:
./configure
make
make install
When your purpose is to test, you will also need a PKCS #11 store for your
private keys. Then you can fill PKCS #11 and the databases.
Build details
-------------
There are three sub-targets with their own Makefiles:
* src/* hosts the daemon, which is an executable named "tlspool"
* lib/* hosts the stub library for applications, and provides:
- "libstarttls.a" and "libstarttls.so" to append to applications
- "tlspool.py" is similar, but used with Python
* tool/* hosts a few demonstration applications, and provides:
- "testcli" and "testsrv" test/demo apps, for line-based chat
- "tlstunnel" as a plaintext-to-TLS or TLS-to-plaintext passthrough
- "webclientdemo.py" and "webserverdemo.py" are Python demonstrations
- "lidsel" and "pinentry" plug into the TLS Pool's localid and PIN services
- "https_proxy.py" demonstrates an intervening HTTPS proxy
The main directory "make" will also make all these subdirectory projects.
Testing
-------
The source package includes a "testdata" directory that can be filled
with databases that you can use for a quick and dirty test. You will
need to setup a PKCS #11 repository; we suggest to use SoftHSMv2 from the
OpenDNSSEC project to get started, you can always try hardware-based
tokens later on. The idea of PKCS #11 is that such choices are pluggable.
To create a SoftHSM token, you can use the following command::
softhsm2-util --init-token --free --label 'TLS_Pool_dev_data'
This label is configured in the default configuration for the TLS Pool.
The default configuration works with a PIN 1234; you can choose any
SO-PIN you like.
You can now build the private keys and from that, certificates that go
into the databases::
cd testdata
make
(If it fails, please run it again.)
The databases may also be rebuilt using the Makefile in the directory,
there are rebuild- clean- and fill- targets for -pkcs11, -cert, -pgp and
-db that will do this for you. Note that rebuilding PKCS #11 is heavy,
it wipes your private key and possibly even the store.
The PKCS #11 data may not be available to your TLS Pool if it runs under
another user, such as the default setup for daemon user "tlspool". If
that is the case, you may need to locate your PKCS #11 store and run
the command; this is for SoftHSMv2::
useradd tlspool
chown -R tlspool:tlspool testdata
chown -R tlspool:tlspool /var/lib/softhsm/tokens/XXX
The following test demonstrates proper working of the TLS Pool based on
the testdata and under the warnings above:
# terminal 1
cd src
./tlspool -kc ../etc/tlspool.conf
# terminal 2
cd src
../tool/testsrv
# termainl 3
cd src
../tool/testcli
This will setup a TLS connection over localhost:12345 and provide a simple
line-by-line chat session between terminals 2 and 3, while showing debugging
output from the TLS Pool in terminal 1. The test client and server are
written to test more functionality as well, and they show some of it too,
namely key agreement based on the master key, which show as matching
"PRNG bytes" in terminals 2 and 3.
A somewhat more complicated test is to actually wrap an existing service
with tunnels:
cd src
./tlspool -kc ../etc/tlspool.conf
../tool/tlstunnel -s -l [::1]:22335 -L [email protected] -r [2001:db8::1234]:80
../tool/tlstunnel -c -l [::1]:22334 -L [email protected] -r [::1]:22335 -R [email protected]
nc ::1 22334
The `tlspool` binary is the TLS Pool itself.
The `tlstunnel -s` is a server-side TLS unwrapper. It receives TLS traffic
on `[::1]:22335`, uses the TLS Pool to unwrap it, and forwards the traffic
to `[2001:db8::1234]:80`, which is a non-existent address but could be replaced
by something like a web server. You should provide your own
IPv6 server address of choice. Note that backward compatibility with IPv4
is available. The identity of the server is `[email protected]`
and that is all that the tunnel needs to know; it will ask the TLS Pool to
fill in the credentials belonging to this identity.
The `tlstunnel -c` is a client-side TLS wrapper. It receives plaintext
traffic on `[::1]:22334`, uses the TLS Pool to wrap it in TLS, and forwards
the traffic to `[::1]:22335`, which was not quite coincidentally configured
before as a TLS-unwrapping server. The client needs to know both its local
identity, `[email protected]`, as the server's. The local identity
is used to access the client credentials, as was done on the server, and the
remote identity is used to determine if the client identity may be disclosed
to this server; furthermore, the identity is used for TLS' Server Name
Indication, which helps with virtual hosting of TLS-secured websites. (And
only websites, really, as all other protocols have embraced a `STARTTLS`
method -- it is mostly everyone's popular protocol in the World that has become
unable to evolve.)
It is admittedly silly to run the client and server on the same machine, but
it serves as a quick test, and isolates any networking trouble that might
creep up in a distributed test.
The identities shown here are in fact a bit silly for a website, which does
not normally use a `user@` part --another thing in which the web is lagging
behind other protocols-- but the applications don't mind that because they
are not aware if the application used is a web server. It is assumed that
the application would not supply silly identifiers in a real setup.
Finally, and perhaps smashingly, this simple demonstration already shows a
power of the TLS Pool: both client and server are capable of using credentials
in the X.509 and OpenPGP formats. WireShark should show you that the client
offers both `cert_type` values in an extension, and the server selects one
that it likes. If the server prefers to use OpenPGP then your luck with
WireShark may change; at the time of this writing, even the newest versions
are unable to decode the OpenPGP certificate type. As a result, a perfectly
good exchange will cry for attention in WireShark, assuming packet formatting
errors.
Running
-------
The tlspool daemon can be run against a configfile of choice, which must
be explicitly configured. My suggestion is to standardise on
/etc/tlspool.conf so the normal script would implement actions with:
* "start" through "tlspool -c /etc/tlspool.conf"
* "stop" through "killall `cat /var/run/tlspool.pid`"
* "restart" through "tlspool -kc /etc/tlspool.conf"
The -k option indicates that any older TLS pool daemon should be kicked
out, if it exists. This will remove its locks on the PID file and sockets.
At present, this will also break off any existing connections. This also
assumes that the PID file is set to /var/run/tlspool.pid and although not
visible here, the socket's default location is /var/run/tlspool.sock
When running the TLS pool as a user without root privileges, a few things
need to be different than in the default configuration:
* "daemon_pidfile" should be in the user's area of control
* "socket_user" and "socket_group" should probably not be set
* "daemon_chroot" cannot be used
* "daemon_user" and "daemon_group" should probably not be set
* "socket_path" and "daemon_pidfile" should be in the user's area
* "memcache_host" should normally not be used
* "pkcs11_path" may be setup for a personally held token device
* "radius_XXX" should normally not be used
We could support a setup with defaults like ~/.tlspool/tlspool.conf for
the configuration, ~/.tlspool/tlspool.pid for the PID file and
~/.tlspool/tlspool.sock for the socket. Note that it can make a lot of
sense to run your own TLS pool within your user account, to avoid
sharing access to your PKCS #11 credentials with others. But doing so
will not automatically incorporate it in system-wide key management
strategies.
Online identities
-----------------
TODO
Testing
-------
Assuming that the TLS pool daemon started successfully, the only thing
that clients and servers need to do is to connect to it and ask it to
STARTTLS over a given file descriptor or socket, and return another one
to replace it. This is implemented in the stub library, for which the
testcli and testsrv programs form a test client and test server,
respectively.
The test programs are best started in their own terminals, so their
input and output does not confuse you. The server starts as any
normal server, creating a listening socket and waiting for input.
We have hardcoded address ::1 or localhost and port 12345 into the
test software. When the client connects, each immediately calls
the STARTTLS operation from their perspective; one starts a TLS client
connection and the other a TLS server connection. Then, typed lines
are passed from one to the other, going through the TLS pool which
takes care of the TLS encryption on the sending side, and the TLS
decryption on the other end.
The TLS pool takes care of authentication, authorization and, if so
desired, even accounting. The basic mode of authentication comes down
to validating certificates as proper online identitites, using such
technologies as LDAP, DANE and DNSSEC. External RADIUS tools can be
added to expand on this, and flag bits may also prove helpful to
modify the TLS pool behaviour in predetermined manners.
The TLS pool also handles teardown in all its forms with grace; that
is, it will detect it immediately and notify the other side.