Ivo Timmermans
2000-Aug-27 15:28 UTC
[URGENT] tinc has a security hole of about 50 million km^2
Sending your passphrase encrypted is all fine, but tinc sends the key with which it was encrypted about a second later... Anyone being able to intercept these two requests is authorized on the VPN. We need asymmetric authentication _now_. -- Ivo Timmermans -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : brouwer.uvt.nl/pipermail/tinc-devel/attachments/20000827/cb7eef42/attachment.pgp
Ivo Timmermans wrote:> Sending your passphrase encrypted is all fine, but tinc sends the key > with which it was encrypted about a second later...What about we establish a shared secret key like we normally do, and then transmit the passphrase encrypted with the secret key? I can't remember why we did it the way it is... And while we're at it, why not just encrypt everything? like this: client server 1 connects to server 2 accepts connection, send HELLO 3 send PUBLIC KEY 4 send PUBLIC KEY From now on, everything can be encrypted. 5 send BASIC INFO 6 send BASIC INFO 7 send PASSPHRASE 8 send PASSPHRASE 9 connected connected -- Ivo Timmermans -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : brouwer.uvt.nl/pipermail/tinc-devel/attachments/20000827/bbb6fcdb/attachment.pgp
Guus Sliepen
2000-Aug-28 16:13 UTC
[URGENT] tinc has a security hole of about 50 million km^2
On Sun, 27 Aug 2000, Ivo Timmermans wrote:> Sending your passphrase encrypted is all fine, but tinc sends the key > with which it was encrypted about a second later...Ehr? How evil! Why didn't we see that earlier? [Pointy accusing fingers into several directions!] Hmm - we had to redefine it anyway. But why does it send the SAME key out? Why not just a different key? That's how it normally works - works as well for symmetric as for assymetric keys, ------------------------------------------- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.warande.net> ------------------------------------------- See also: tinc.nl.linux.org kernelbench.org ------------------------------------------- --- TINC development list, tinc-devel@nl.linux.org Archive: mail.nl.linux.org/tinc-devel
On Sun, 27 Aug 2000, Ivo Timmermans wrote: [...]> From now on, everything can be encrypted. > > 5 send BASIC INFO > 6 send BASIC INFO > 7 send PASSPHRASE > 8 send PASSPHRASE > 9 connected connectedThese also have to be encrypted, because you are still not sure about the identity of both sides. So even over the session-encrypted line, you have to send authentication-encrypted passphrases. ------------------------------------------- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.warande.net> ------------------------------------------- See also: tinc.nl.linux.org kernelbench.org ------------------------------------------- --- TINC development list, tinc-devel@nl.linux.org Archive: mail.nl.linux.org/tinc-devel
Guus Sliepen
2000-Aug-29 10:47 UTC
[URGENT] tinc has a security hole of about 50 million km^2
On Sun, 27 Aug 2000, Ivo Timmermans wrote:> Sending your passphrase encrypted is all fine, but tinc sends the key > with which it was encrypted about a second later...I think you worried too much, but I might be wrong on the following explanation, so please read it carefully: Tinc generates a public/private key pair on startup. It encrypts it's own passphrase with it's public key. This means, that only one with the corresponding private key can decrypt that. The other side however, if he also has a copy of your passphrase, can VERIFY the passphrase by encrypting it with the public key you send later. You cannot decrypt it though, so neither the other endpoint nor a man in the middle can decypher our passphrase if they do not already have it in plaintext. The order in which the passphrases and the keys are sent do not matter. ------------------------------------------- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.warande.net> ------------------------------------------- See also: tinc.nl.linux.org kernelbench.org ------------------------------------------- --- TINC development list, tinc-devel@nl.linux.org Archive: mail.nl.linux.org/tinc-devel