[14300] in cryptography@c2.net mail archive
Re: Tinc's response to "Linux's answer to MS-PPTP"
daemon@ATHENA.MIT.EDU (Joseph Ashwood)
Fri Sep 26 23:10:56 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: "Joseph Ashwood" <ashwood@msn.com>
To: <cryptography@metzdowd.com>
Date: Fri, 26 Sep 2003 18:26:16 -0700
And a response. I have taken the liberty of copying the various portions of
the contents of the webpage to this email for response. I apologize for the
formatting confusion which may mistake Peter Gutmann's comments with those
of the semi-anonymous misinformed person under scrutiny.
I would have CC'd the author of the response page, but it fails to mention
an author, in spite of the "Comments are welcome" statement at the
beginning.
> On September the 15th Peter Gutmann contacted us and showed us part of a
writeup which he
> posted to a cryptography mailing list on the 22th. In this writeup he
identifies several security issues
> in CIPE, VTun and tinc. Below we will examine his findings and explain why
some flaws or
> weaknesses Peter Gutmann found are in fact not a problem at all for a VPN
daemon like tinc.
> As a reader you are ultimately left to draw your own conclusions, I
encourage you to read all the
> arguments from both sides and, if possible, verify them by reading the
documentation and source
> code of tinc. Comments are welcome.
> Predictable IV
Proposed solution: provide the option of a "full IV and move the sequence
number out of the ciphertext," note that this is an _option_, instead of the
necessary for security always.
> Truncated MAC
> tinc will continue to use only the first 32 bits by default.
Simply put this is unacceptable from a security standpoint. The view taken
is that the extra 128 bits represents a significant overhead in the
communication. So I did the math, sending the extra 128 bits over a 52kbs
would take 0.002 seconds, and over a T1 the time cost is an absolutely
enormous 0.00008 seconds. The other consideration is the potentially the
computation time argument, but SHA-1 is used regardless, the computation
time is identical. There is no justification in even a dialup environment
for not using the full HMAC.
> Use of RSA
> Tinc uses RSA encryption only once, during authentication.
<sarcasm> Yeah authentication is such a minor thing that major flaws are
completely aceptable.</sarcasm>
> A message is sent which has the same length as the RSA key, and is
> completely filled . . .using real random data (OpenSSL's RAND_bytes()).
I really wish people would actually read documentation *before* making
stupid claims like this, in fact to quote the OpenSSL docs "These functions
implement a cryptographically secure pseudo-random number generator (PRNG).
" Any claim that OpenSSL implements a "real" random number generator are
completely false.
> So, the message does not have low entropy and doesn't contain predictable
> bits.
Read the docs, the message has 0 entropy (actually marginally above 0, but
these are simple rounding errors), that's what a pseudo-random number
generator means.
> However, there is no guarantee that the message was encrypted using the
> correct public key or that noone has tampered with it. This is of no
concern
> for tinc though.
There goes that authentication doesn't matter problem again, remind is tinc
supposed to have any sembalnce of security? or is it just a stupid toy
designed for young children to keep they're even younger siblings out of
their personal matters?
> Part of the message is used as the key for the symmetric cipher that is
used
> by the sender of this key to encrypt the rest of the messages it will
send. A
> challenge-response exchange right after exchanging the RSA encrypted
> messages is done to ensure that both the sender of the symmetric cipher
key
> has the right public key, the recipient has the right corresponding
private
> key, and the message was not tampered with (because that would change the
> symmetric cipher key).
Whoever designed and stated this has no idea about cryptographic security.
Using a "part" of a shared secret, generated by a pRNG on only one side,
introduces horrific flaws in the protocol. Pretending that poorly done RSA
encryption magically solves the problem will only risk everything that has
ever been encrypted using tinc.
> Authentication protocol
> 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).
Good luck keeping that assumption true, with the oracle attack listed above
that won't stay true very long at all.
> 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.
But he does, he spoofed each connection and acted as initiator for both, now
it's a simple matter of resending. Your entire model is based on a
misunderstanding of what RSA does and does not offer.
What you're missing is that the connection iniator sets all the keys and can
determine all the keys (assuming the uncontested simplified message flow is
correct). Mallet can very easily perform a complete man-in-the-middle attack
> Configuration
skipped, configuration is the least of the issues here.
> General issues
> - Don't use the same key for encryption and authentication.
> Nowhere in the authentication protocol does this happen.
Everywhere in the authentication protocol does this happen. RSA is used only
once, and only a public key is necessary. From there the keys are a
derivative of the same key, so the same key is used for encryption and
authentication.
> - 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.
My guess is that you will once again use it in an insecure method, use
either signed ephemeral keys, or introduce randomness form both sides,
otherwise you will have the same problems from slightly different angles.
> - 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.
Completely incorrect. When Mallet(Alice) contacts Bob, Bob is authenticated,
but Mallet(Alice) is not. Additionally Bob is not properly authenticated due
to the gaping holes in the initial protocol.
> - Don't use the same messages in both directions.
> Tinc doesn't send the same messages, it sends the same kinds of messages.
Exactly the problem. Once a message type has been sent in the connection,
change the message type (even if it's just a transfer number), this will
address yet another gaping hole.
> - 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.
You provide all the chosen ciphertext information Mallet could want. You act
as an 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.
Only the really bad ones, all the ones that are used by real cryptographic
engineers miss attacks by large amounts.
> Thoughts
> VTun even mentions it is not intended to be
> secure, and CIPE focuses more on usability than on security.
And tinc goes out of it's way to avoid any semblance of good security.
> Furthermore, SSL and SSH are
> reliable stream based protocols, unsuitable for VPNs
Someone doesn't pay much attention to what they write. Both SSL and SSH
_ARE_ VPN protocols, that you don't recognise them as such reflects a great
deal on lack of knowledge in the area of security.
> [VPNs] work best with unreliable datagrams
Ummmm, do you realize how dumb that sounds?
> Both SSL and SSH have had their security
> problems . . , as perfect as Peter Gutmann would let us believe.
They may not be perfect but in neither case can Mallet do as much damage as
easily, even the recent break in OpenSSH did not allow a compromise as big
as even the smallest of the problems briefly explored in tinc.
> 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.
Yeah but the "great names" admit they are wrong, and fix things. You have
instead taken every possible moment to insist that tinc is good, something
that even the barest educated layperson can see is simply and completely
false.
> 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.
I think here Gutmann went a bit overboard in his recommendation, but
regardless the idea that someone should replace SSH/SSL with something
designed by an amateur without the knowledge necessary to make it correct is
a bad idea. In fact I have several years of experience and I have a
potential replacement protocol that I think may in some cases be better than
SSL/SSH, even with my experience I have held off publishing it for about 4
years now while I verify that it will in fact stand up to attack. How long
was it between the inducement of this idea and it's release?
> We have no obligation to justify anything we do. We also do not believe
SSL
> is the be-all, end-all of cryptography.
Actually you have that backwards. In security you have every obligation to
justify every single portion of every line of code in every product.
However, SSL is far from the be-all, end-all of security. In fact if it were
Gutmann would have simply recommended that everyone use one of the many
SSL-VPN products available (in spite of the errant belief that SSL is
"unsuitable for VPNs").
If anyone wants to make a toy that is only useful at keeping baby siter
grade atackers out tinc is suitable (at least until someone writes a small
script to perform any of the numerous breaks outlined by Gutmann), for
anyone that actually needs to protect something worth more than $0.05 use
something that offers real security.
Joe
Trust Laboratories
Changing Software Development
http://www.trustlaboratories.com
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
