decrypt udp tunnel

[Guus Sliepen]

On Tue, May 22, 2012 at 11:46:10AM -0300, Lucas Aimaretto wrote:

> Now, I was curious and wanted to actually see the udp tunnel protocol
> stack. Googling a little bit -does this expression exist?- I've found
> out that one could associate each end-point's private-key and
> wireshark would do the rest (my guess is that by using the private key
> wireshark will then work out the public one in order to decrypt
> traffic). However, all the examples that I've found are related to
> HTTPS which is not exactly my case since, for example, when issuing
> some pings from one peer to the other, the protocol stack of tinc (I'm
> guessing) would by like this:
> 
> +-----------------------+
> | ICMP                  |
> +-----------------------+
> | IP_remote_LAN         |
> +-----------------------+
> | SSL (or something)    |
> +-----------------------+
> | UDP (port 655)        |
> +-----------------------+
> | IP_tunnel             |
> +-----------------------+

It is not SSL, it is indeed "or something", but the rest of your diagram is
more or less correct. Most parts of the protocol tinc uses are documented, have
a look at the files in the doc/ directory. However, it's not so simple; you
have the meta-connections, which run over TCP, which do authentication using
public/private keys. If you have the private key of all the nodes you have
meta-connections with, you can in principle decrypt all the traffic. For UDP,
session keys are exchanged between nodes via the meta-connections. The UDP
packets are encrypted using these session keys. However, to know which session
key to use, you have to know which node a packet is for. So you need to decode
also those parts of the meta protocol that map addresses to nodes. It is far
from trivial to add a tinc packet decoder to something like wireshark, I think.
If you want to know what is going on on the VPN, you can just monitor the VPN
interface of course.

In the 1.1 branch in tinc's git repository, there is an experimental protocol
which uses ephemeral Diffie-Hellman key exchange to generate the session keys.
It only uses the static public/private keys to sign the ephemeral keys. That
means a packet sniffer cannot decrypt the traffic even if you have all the
private keys (unless of course you perform a man-in-the-middle attack using
those private keys).

If you just want to understand how tinc works, you can disable UDP packet
encryption using "Cipher = none", and by disabling meta-connection encryption
using the --bypass-security option when starting tinc.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20120523/70afb2e2/attachment.pgp>