1CURVETUN(8)                   netsniff-ng toolkit                  CURVETUN(8)
2
3
4

NAME

6       curvetun - a lightweight curve25519 ip4/6 tunnel
7

SYNOPSIS

9       curvetun [options]
10

DESCRIPTION

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

OPTIONS

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

USAGE EXAMPLE

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

CRYPTOGRAPHY

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

SETUP HOWTO

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

NOTE

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

BUGS

357       Blackhole tunneling is currently not supported.
358
360       curvetun is licensed under the GNU GPL version 2.0.
361

HISTORY

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

SEE ALSO

368       netsniff-ng(8),  trafgen(8),  mausezahn(8),  bpfc(8),  ifpps(8),  flow‐
369       top(8), astraceroute(8)
370

AUTHOR

372       Manpage was written by Daniel Borkmann.
373

COLOPHON

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)
Impressum