mausezahn: use getopt_long instead of getopt
[netsniff-ng.git] / curvetun.8
blob2b2cb25f90d391bcb076e59b0ce7055f76f9c90e
1 .\" netsniff-ng - the packet sniffing beast
2 .\" Copyright 2013 Daniel Borkmann.
3 .\" Subject to the GPL, version 2.
4 .TH CURVETUN 8 "03 March 2013" "Linux" "netsniff-ng toolkit"
5 .SH NAME
6 curvetun \- a lightweight curve25519 ip4/6 tunnel
7 .PP
8 .SH SYNOPSIS
9 .PP
10 \fBcurvetun\fP [\fIoptions\fP]
11 .PP
12 .SH DESCRIPTION
13 curvetun is a lightweight, high-speed ECDH multiuser IP tunnel for Linux
14 that is based on
15 .BR epoll (2).
16 curvetun uses the Linux TUN/TAP interface and supports {IPv4, IPv6} over {IPv4,
17 IPv6} with UDP or TCP as carrier protocols.
18 .PP
19 It has an integrated packet forwarding tree, thus multiple users with
20 different IPs can be handled via a single tunnel device on the server side,
21 and flows are scheduled for processing in a CPU efficient way, at least in the
22 case of TCP as the carrier protocol.
23 .PP
24 For key management, public-key cryptography based on elliptic curves are
25 used and packets are encrypted end-to-end by the symmetric stream cipher
26 Salsa20 and authenticated by the MAC Poly1305, where keys have previously
27 been computed with the ECDH key agreement protocol Curve25519.
28 .PP
29 Cryptography is based on Daniel J. Bernstein's networking and cryptography
30 library \[lq]NaCl\[rq]. By design, curvetun does not provide any particular
31 pattern or default port numbers that gives certainty that the connection from
32 a particular flow is actually running curvetun.
33 .PP
34 However, if you have a further need to bypass censorship, you can try using
35 curvetun in combination with Tor's obfsproxy or Telex. Furthermore, curvetun
36 also protects you against replay attacks and DH man-in-the-middle attacks.
37 Additionally, server-side syslog event logging can also be disabled to avoid
38 revealing critical user connection data.
39 .PP
40 .IP " 1." 4
41 obfsproxy from the TOR project
42 .RS 4
43 \%https://www.torproject.org/projects/obfsproxy.html.en
44 .RE
45 .PP
46 .IP " 2." 4
47 Telex, anti-censorship in the network infrastructure
48 .RS 4
49 \%https://telex.cc/
50 .RE
51 .PP
52 .SH OPTIONS
53 .TP
54 .B -d <tundev>, --dev <tundev>
55 Defines the name of the tunnel device that is being created. If this option
56 is not set, then the default names, curves{0,1,2,..} for a curvetun server,
57 and curvec{0,1,2,...} for a curvetun client are used.
58 .TP
59 .B -p <num>, --port <num>
60 Defines the port the curvetun server should listen on. There is no default port
61 for curvetun, so setting this option for server bootstrap is mandatory. This
62 option is for servers only.
63 .TP
64 .B -t <server>, --stun <server>
65 If needed, this options enables an STUN lookup in order to show public IP to port
66 mapping and to punch a hole into the firewall. In case you are unsure what STUN
67 server to use, simply use ''\-\-stun stunserver.org''.
68 .TP
69 .B -c[=alias], --client[=alias]
70 Starts curvetun in client mode and connects to the given connection alias that is
71 defined in the configuration file.
72 .TP
73 .B -k, --keygen
74 Generate private and public keypair. This must be done initially.
75 .TP
76 .B -x, --export
77 Export user and key combination to stdout as a one-liner.
78 .TP
79 .B -C, --dumpc
80 Dump all known clients that may connect to the local curvetun server and exit.
81 .TP
82 .B -S, --dumps
83 Dump all known servers curvetun as a client can connect to, and exit.
84 .TP
85 .B -D, --nofork
86 Do not fork off as a client or server on startup.
87 .TP
88 .B -s, --server
89 Start curvetun in server mode. Additional parameters are needed, at least
90 the definition of the port that clients can connect to is required.
91 .TP
92 .B -N, --no-logging
93 Disable all curvetun logging of user information. This option can be used to
94 enable curvetun users to connect more anonymously. This option is for servers
95 only.
96 .TP
97 .B -u, --udp
98 Use UDP as a carrier protocol instead of TCP. By default, TCP is the
99 carrier protocol. This option is for servers only.
101 .B -4, --ipv4
102 Defines IPv4 as the underlying network protocol to be used on the tunnel
103 device. IPv4 is the default. This option is for servers only.
105 .B -6, --ipv6
106 Defines IPv6 as the underlying network protocol to be used on the tunnel
107 device. This option is for servers only.
109 .B -v, --version
110 Show version information and exit.
112 .B -h, --help
113 Show user help and exit.
115 .SH USAGE EXAMPLE
117 .B curvetun --server -4 -u -N --port 6666 --stun stunserver.org
118 Starts curvetun in server mode with IPv4 as network protocol and UDP as a transport
119 carrier protocol. The curvetun server listens for incoming connections on port 6666
120 and performs an STUN lookup on startup to stunserver.org.
122 .B curvetun --client=ethz
123 Starts curvetun in client mode and connects to the defined connection alias ''ethz''
124 that is defined in the curvetun ~/.curvetun/servers configuration file.
126 .B curvetun --keygen
127 Generates initial keypairs and stores them in the ~/.curvetun/ directory.
129 .B curvetun --export
130 Export user data to stdout for configuration of a curvetun server.
132 .SH CRYPTOGRAPHY
133 Encrypted IP tunnels are often used to create virtual private networks (VPN),
134 where parts of the network can only be reached via an insecure or untrusted medium
135 such as the Internet. Only a few software utilities exist to create such tunnels,
136 or, VPNs. Two popular representatives of such software are OpenVPN and VTUN.
138 The latter also introduced the TUN/TAP interfaces into the Linux kernel. VTUN
139 only has a rather basic encryption module, that does not fit today's
140 cryptographic needs. By default, MD5 is used to create 128-Bit wide keys for
141 the symmetric BlowFish cipher in ECB mode [1].
143 Although OpenSSL is used in both VTUN and OpenVPN, OpenVPN is much more
144 feature rich regarding ciphers and user authentication. Nevertheless, letting
145 people choose ciphers or authentication methods is not necessarily a
146 good thing: administrators could either prefer speed over security and
147 therefore choose weak ciphers, so that the communication system will be as
148 good as without any cipher; they could choose weak passwords for symmetric
149 encryption or they could misconfigure the communication system by having too
150 much choice of ciphers and too little experience for picking the right one.
152 Next to the administration issues, there are also software development issues.
153 Cryptographic libraries like OpenSSL are a huge mess and too low-level and
154 complex to fully understand or correctly apply, so that they form further
155 ground for vulnerabilities of such software.
157 In 2010, the cryptographers Tanja Lange and Daniel J. Bernstein have therefore
158 created and published a cryptographic library for networking, which is named
159 NaCl (pronounced ''salt''). NaCl addresses such problems as mentioned in
160 OpenSSL and, in contrast to the rather generic use of OpenSSL, was created
161 with a strong focus on public-key authenticated encryption based on elliptic
162 curve cryptography, which is used in curvetun. Partially quoting Daniel J.
163 Bernstein:
165 "RSA is somewhat older than elliptic-curve cryptography: RSA was introduced
166 in 1977, while elliptic-curve cryptography was introduced in 1985. However,
167 RSA has shown many more weaknesses than elliptic-curve cryptography. RSA's
168 effective security level was dramatically reduced by the linear sieve in the
169 late 1970s, by the quadratic sieve and ECM in the 1980s, and by the
170 number-field sieve in the 1990s. For comparison, a few attacks have been
171 developed against some rare elliptic curves having special algebraic
172 structures, and the amount of computer power available to attackers has
173 predictably increased, but typical elliptic curves require just as much
174 computer power to break today as they required twenty years ago.
176 IEEE P1363 standardized elliptic-curve cryptography in the late 1990s,
177 including a stringent list of security criteria for elliptic curves. NIST
178 used the IEEE P1363 criteria to select fifteen specific elliptic curves at
179 five different security levels. In 2005, NSA issued a new ''Suite B''
180 standard, recommending the NIST elliptic curves (at two specific security
181 levels) for all public-key cryptography and withdrawing previous
182 recommendations of RSA."
184 curvetun uses a particular elliptic curve, Curve25519, introduced in the
185 following paper: Daniel J. Bernstein, ''Curve25519: new Diffie-Hellman speed
186 records,'' pages 207-228 in Proceedings of PKC 2006, edited by Moti Yung,
187 Yevgeniy Dodis, Aggelos Kiayias, and Tal Malkin, Lecture Notes in Computer
188 Science 3958, Springer, 2006, ISBN 3-540-33851-9.
190 This elliptic curve follows all of the standard IEEE P1363 security criteria.
191 It also follows new recommendations that achieve ''side-channel immunity''
192 and ''twist security'' while improving speed. What this means is that secure
193 implementations of Curve25519 are considerably simpler and faster than secure
194 implementations of, for example, NIST P-256; there are fewer opportunities for
195 implementors to make mistakes that compromise security, and mistakes are
196 more easily caught by reviewers.
198 An attacker who spends a billion dollars on special-purpose chips to attack
199 Curve25519, using the best attacks available today, has about 1 chance in
200 1000000000000000000000000000 of breaking Curve25519 after a year of computation.
201 One could achieve similar levels of security with 3000-bit RSA, but
202 encryption and authentication with 3000-bit RSA are not nearly fast enough
203 to handle tunnel traffic and would require much more space in network
204 packets.
206 .IP " 1." 4
207 Security analysis of VTun
208 .RS 4
209 \%http://www.off.net/~jme/vtun_secu.html
212 .IP " 2." 4
213 NaCl: Networking and Cryptography library
214 .RS 4
215 \%http://nacl.cr.yp.to/
218 .SH SETUP HOWTO
219 If you have not run curvetun before, you need to do an initial setup once.
221 First, make sure that the servers and clients clocks are periodically
222 synced, for example, by running an NTP daemon. This is necessary to protect
223 against replay attacks. Also, make sure you have read and write access to
224 /dev/net/tun. You should not run curvetun as root! Then, after you have assured
225 this, the first step is to generate keys and config files. On both the client
226 and server do:
228 .B curvetun -k
230 You are asked for a user name. You can use an email address or whatever suits
231 you. Here, we assume you have entered 'mysrv1' on the server and 'myclient1'
232 on the client side.
234 Now, all necessary files have been created under ~/.curvetun. Files include
235 \[lq]priv.key\[rq], \[lq]pub.key\[rq], \[lq]username\[rq], \[lq]clients\[rq]
236 and \[lq]servers\[rq].
238 \[lq]clients\[rq] and \[lq]servers\[rq] are empty at the beginning and need
239 to be filled. The \[lq]clients\[rq] file is meant for the server, so that it
240 knows what clients are allowed to connect. The \[lq]servers\[rq] file is for
241 the client, where it can select curvetun servers to connect to. Both files are
242 kept very simple, so that a single configuration line per client or server
243 is sufficient.
245 The client needs to export its public key data for the server
247 .B curvetun -x
249 where it prints a string in the following format:
251   myclient1;11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11
252   \\_______/ \\_____________________________________________________________________________________________/
253    username  32 byte public key for 'myclient1'
255 This line is transferred to the server admin (yes, we assume a manual on-site
256 key exchange scenario where, for example, the admin sets up server and clients), where
257 the admin then adds this entry into his ''clients'' file like:
259   server$ echo "myclient1;11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:" \\
260                "11:11:11:11:11:11:11:11:11:11:11:11:11:11:11" >> ~/.curvetun/clients
262 The server admin can check if the server has registered it properly as follows:
264   server$ curvetun \-C
266 which prints all parsed clients from ''~/.curvetun/clients''. This process could
267 easily be automated or scripted with, for example, Perl and LDAP.
269 Now, the client ''myclient1'' is known to the server; that completes the server
270 configuration. The next step is to tell the client where it needs to connect to
271 the server.
273 We assume in this example that the tunnel server has a public IP address, e.g. 1.2.3.4,
274 runs on port 6666 and uses UDP as a carrier protocol. In case you are behind
275 NAT, you can use curvetun's ''\-\-stun'' option for starting the server, to
276 obtain your mapping. However, in this example we continue with 1.2.3.4 and 6666,
277 UDP.
279 First, the server needs to export its key to the client, as follows:
281   server$ curvetun \-x
283 where it prints a string in the following format:
285   mysrv1;22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22
286   \\____/ \\_____________________________________________________________________________________________/
287  username  32 byte public key for 'mysrv1'
288            ^-- you need this public key
290 Thus, you now have the server IP address, server port, server transport protocol and the
291 server's public key at hand. On the client side it can be put all together
292 in the config as follows:
294   client$ echo "myfirstserver;1.2.3.4;6666;udp;22:22:22:22:22:22:22:22:22:22:" \\
295                "22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:"  \\
296                "22:22" >> ~/.curvetun/servers
298 The client can check its config using:
300   client$ curvetun \-S
302 Then we start the server with:
304   server$ curvetun \-s \-p 6666 \-u
305   server# ifconfig curves0 up
306   server# ifconfig curves0 10.0.0.1/24
308 Then, we start the client with:
310   client$ curvetun \-c=myfirstserver
311   client# ifconfig curvec0 up
312   client# ifconfig curvec0 10.0.0.2/24
314 Also, client-side information, errors, or warnings will appear in syslog! By now
315 we should be able to ping the server:
317   client$ ping 10.0.0.1
319 That's it! Routing example:
321 Server side's public IP on eth0 is, for example, 1.2.3.4:
323   server$ ... start curvetun server ...
324   server# ifconfig curves0 up
325   server# ifconfig curves0 10.0.0.1/24
326   server# echo 1 > /proc/sys/net/ipv4/ip_forward
327   server# iptables \-t nat \-A POSTROUTING \-o eth0 \-j MASQUERADE
328   server# iptables \-A FORWARD \-i eth0 \-o curves0 \-m state \-\-state RELATED,ESTABLISHED \-j ACCEPT
329   server# iptables \-A FORWARD \-i curves0 \-o eth0 \-j ACCEPT
331 Client side's IP on eth0 is, for example, 5.6.7.8:
333   client$ ... start curvetun client ...
334   client# ... lookup your default gateway (e.g. via route, here: 5.6.7.9) ...
335   client# ifconfig curvec0 up
336   client# ifconfig curvec0 10.0.0.2/24
337   client# route add \-net 1.2.3.0 netmask 255.255.255.0 gw 5.6.7.9 dev eth0
338   client# route add default gw 10.0.0.1
339   client# route del default gw 5.6.7.9
341 That should be it, happy browsing and emailing via curvetun tunnels!
343 .SH NOTE
344 This software is an experimental prototype intended for researchers. It will most
345 likely mature over time, but it is currently not advised to use this software
346 when life is put at risk.
348 .SH BUGS
349 Blackhole tunneling is currently not supported.
351 .SH LEGAL
352 curvetun is licensed under the GNU GPL version 2.0.
354 .SH HISTORY
355 .B curvetun
356 was originally written for the netsniff-ng toolkit by Daniel Borkmann. It is
357 currently maintained by Tobias Klauser <tklauser@distanz.ch> and Daniel
358 Borkmann <dborkma@tik.ee.ethz.ch>.
360 .SH SEE ALSO
361 .BR netsniff-ng (8),
362 .BR trafgen (8),
363 .BR mausezahn (8),
364 .BR bpfc (8),
365 .BR ifpps (8),
366 .BR flowtop (8),
367 .BR astraceroute (8)
369 .SH AUTHOR
370 Manpage was written by Daniel Borkmann.
372 .SH COLOPHON
373 This page is part of the Linux netsniff-ng toolkit project. A description of the project,
374 and information about reporting bugs, can be found at http://netsniff-ng.org/.