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