-> *Beyond that, the [protocol writeup](http://www.tinc-vpn.org/documentation/tinc_6.html#SEC61) points out that:*
-> > the server sends exactly the same kind of messages over the wire as
-> > the client
->
-> *In case the problem isn't obvious yet, note that what's being exchanged is purely a random bit string, with no binding of client or server roles or identities into any part of the exchange. Again, there are way too many references to cite on these issues, although my favourite coverage of a lot of the things you need to think about is in "Network Security: Private Communication in a Public World" by Kaufman, Perlman, and Speciner.*
-
-There are no server and client roles in tinc, because it is
-peer-to-peer. When a new TCP connections is made, both peers have
-to authenticate themselves to eachother, and both have to be
-configured to trust the other to let the authentication succeed. We
-do not see how this remark about tinc not identifying a server and
-a client diminishes security.
-
-> *As an example, here's a simple attack. The documentation (section 6.3.1) is a bit vague about the message flow, but assuming I've understood it correctly, the message flow is:*
-> client server
-> rsa( random_key ) -->
-> random_key( challenge ) -->
-> <-- random_key( sha1( challenge ) )
->
-> *Simplifying things a bit so that the entire exchange can be abstracted down to "challenge" and "response" (with implied RSA decryption, etc etc taking place as part of that), let's say Mallet wants to mess with Alice and Bob. So Mallet sends a challenge to Bob (claming to be Alice) and gets back a response. Mallet gets Bob's encrypted key and challenge back and forwards it to Alice, who returns a response, which Mallet in turn forwards to Bob, a classic chess grandmaster attack. Bob now thinks he's talking to Alice, when in fact Mallet controls one of the two channels.*
-
-First of all, we assume Mallet does not know the private keys of
-Bob and Alice (Bob and Alice are not compromised), and Bob and
-Alice do not know Mallet at all (they don't trust Mallet, otherwise
-he could've made a connection without having to resort to a
-cryptographic attack). We do assume that Mallet knows the public
-keys of Alice and Bob. First, keys for the symmetric cipher
-encryption are exchanged. Mallet cannot decrypt keys he gets from
-Bob and Alice, because he doesn't have their private keys. He can
-send his own keys, encrypted with Bob and Alice's public keys. So
-after the key exchange, Mallet can send plaintext to Bob and Alice,
-which will decrypt them correctly, but he cannot read the plaintext
-Bob and Alice send to him. So Mallet sends a challenge to Bob, who
-can decrypt it, and Bob returns a response which Mallet cannot
-read. Mallet cannot decrypt it, reencrypt it and send it to Alice,
-and neither can he forward the ciphertext from Bob to Alice,
-because Alice uses a different key to decrypt messages from Mallet
-than Bob uses to encrypt messages to Mallet. Hence, this attack
-won't work, and Peter Gutmann is wrong on this point.
-
-### Configuration
-
-> *As an extension of the handshake problem, tinc relies heavily on an administrator at both ends of the link configuring the software identically for the handling of the handshake phase, replacing the authenticated parameter negotiation performed by protocols like SSL/TLS, SSH, and IPsec (during the data transfer phase there are ways of negotiating parameters, I haven't looked at this too much).*
-
-Tinc does not have to be configured identically on each endpoint.
-When making an encrypted connection between to hosts, it is common
-to negotiate which cipher to use. However, tinc does not just
-create a tunnel between two endpoints, it can handle any number of
-endpoints. Because it is very hard to negotiate a single cipher for
-all endpoints, tinc does not negotiate, and allows each endpoint to
-choose which cipher should be used to encrypt packets to it,
-regardless of what cipher the other endpoints use. This does not
-compromise security in itself, and in fact this might even improve
-security.
-On the other hand an administrator of one endpoint might choose to
-use an insecure cipher instead of the default, and compromise
-traffic other endpoints send to it. Tinc could be rewritten to
-always enforce the use of the strongest cipher, but we believe you
-should trust every participant in the VPN, and if one administrator
-is not trustworthy, he should be removed from the VPN: even with
-enforcement of strong ciphers, a malicious participant could just
-as easily post all the VPN traffic he receives on a website, so it
-really doesn't improve security at all.
-
-### General issues
-
-> *- Don't use the same key for encryption and authentication.*
-
-Nowhere in the authentication protocol does this happen.
-
-> *- Don't have the key chosen entirely by one side (even if it's only Alice and Bob on the line rather than Mallet, if one of the two has a poor RNG, all communications from them are compromised).*
-
-This is a valid point. Tinc can easily be changed to use keys
-composed of what both sides send, for example by using the
-Diffie-Helman scheme. This is planned for tinc 2.0.
-
-> *- Provide message freshness guarantees (and, if possible, some form of PFS).*
-
-Currently only the UDP packets sent by tinc have PFS, but this is
-not true for the TCP connections (the meta protocol). This will be
-resolved in tinc 2.0.
-
-> *- Bind the identity of the principals to the authentication.*
-
-The authentication is done using RSA encryption, the RSA keys are
-directly bound to the identities of the tinc daemons.
-
-> *- Don't use the same messages in both directions.*
-
-Tinc doesn't send the same messages, it sends the same *kinds* of
-messages.
-
-> *- Don't act as an oracle for an attacker.*
-
-Apart from possibly being susceptible to a timing attack, we don't
-believe, and Peter Gutmann has not convinced us, that tinc can be
-used as any other kind of oracle.
-
-> *As it stands the handshake protocol only narrowly avoids a variety of basic attacks, making it quite brittle in that the most trivial change (or someone thinking about possible attacks a bit further :-) would probably kill it.*
-
-I think this holds for virtually all cryptographic handshake
-protocols.
-
-### Thoughts
-
-> *These programs have been around for years (CIPE goes back to 1996 and vtun to 1998) and (apparently) have quite sizeable user communities without anyone having noticed (or caring, after flaws were pointed out) that they have security problems. I only heard of CIPE when a friend of mine mentioned it to me in passing, and came across vtun by coincidence when I was looking for more info on CIPE. Who knows how many more insecure Linux crypto-tunnel products there may be floating around out there.*
-
-Although security can only be proven by time and peer review, the
-lack of some people noticing certain software applications does not
-have a direct relation to their security. The fact that Peter
-Gutmann only examined three specific Open Source VPN products does
-not say anything about the security of other products.
-
-> *It's possible to create insecure "security" products just as readily with open-source as with closed-source software.*
-
-I don't think anyone disagrees with that.
-
-> *CIPE and vtun must be the OSS community's answer to Microsoft's PPTP implementation. What's even worse is that some of the flaws were pointed out nearly two years ago, but despite the hype about open-source products being quicker with security fixes, some of the protocols still haven't been fixed. At least Microsoft eventually tries to fix their stuff, given sufficient public embarrassment and the odd hundred thousand or so computers being taken out by attackers.*
-
-Microsoft sells its products as being secure, and the people who
-buy its products have expectations. But not everyone is out there
-to make software that is as secure as possible, VTun even mentions
-it is not intended to be secure, and CIPE focuses more on usability
-than on security.
-
-> *For all of these VPN apps, the authors state that they were motivated to create them as a reaction to the perceived complexity of protocols like SSL, SSH, and IPsec. The means of reducing the complexity was to strip out all those nasty security features that made the protocols complex (and secure). Now if you're Bruce Schneier or Niels Ferguson, you're allowed to reinvent SSL ("Practical Cryptography", John Wiley & Sons, 2003). Unfortunately the people who created these programs are no Bruce or Niels. The results are predictable.*
-
-Development of CIPE, VTun and tinc has started in times when SSH,
-SSL and IPsec were nowhere as popular as they are now. We certainly
-never claimed we created tinc in reaction to those protocols.
-Furthermore, SSL and SSH are reliable stream based protocols,
-unsuitable for VPNs which work best with unreliable datagrams,
-hence it wouldn't have been an obvious choice to use SSH or SSL in
-the first place. Both SSL and SSH have had their security problems
-in the past (and in the case of OpenSSH, even in the recent past),
-emphasizing that even these widely used and scrutinised protocols
-are not as perfect as Peter Gutmann would let us believe.
-Apart from that, there is no reason why people shouldn't create new
-protocols, which might in time become just as strong or even
-stronger. Even great names as Ron Rivest didn't get it right the
-first time.
-
-> *Whenever someone thinks that they can replace SSL/SSH with something much better that they designed this morning over coffee, their computer speakers should generate some sort of penis-shaped sound wave and plunge it repeatedly into their skulls until they achieve enlightenment.*
-
-A very professional and constructive argument.
-
-> *Replacing the SSL/SSH data channel is marginally justifiable, although usually just running SSL/SSH over UDP would be sufficient. Replacing the SSL/SSH control channel is never justifiable - even the WAP guys, with strong non-SSL/SSH requirements, simply adapted SSL rather than trying to invent their own protocol.*
-
-We have no obligation to justify anything we do. We also do not
-believe SSL is the be-all, end-all of cryptography.