tincd.exe -K (sorry if present twice)

[Axel Christiansen]

Guus Sliepen wrote:

>>BTW. Can you or anyone else see a proplam in the fact, that the
>>public part of the key of both sides travel in clear text
>>over the net? I use RPC to exchange the pub keys and ip config.
> 
> 
> There is no problem with sending public keys in cleartext, that's why
> they are "public". An eavesdropper cannot learn anything useful from a
> public key alone.
> 
> There is a problem in exchanging public keys in an automated fashion
> though: a man in the middle could intercept a public key, replace it
> with its own public key, and pass it on. Both sides think they got a
> public key from eachother, while in reality they got keys from the man
> in the middle, and the man in the middle will be able to decrypt all the
> traffic that is being sent.
> 
> You should never just trust a public key, you should verify that it
> comes from the right person (which you can do easily yourself by talking
> to that person), or you should sign the public key with another trusted
> key, like with X.509 certificates or PGP signatures.
> 
> Could you tell us why you're dynamically exchanging public keys?

I am working on a tinc GUI for windows with a specific purpose.
The app is done with python and is pretty close to it's first use.

It will be deployed for a WISP. The WISP has its customer authentication
and billing all included in a WISP management app. www.wificom.com.

Therefore there is no need for authentication at user level but for
a easy to use encryption. WEP keys in public hotspots is useless and
other types of encryption is not widely popular. And, lets say the
common websurfer is often swamped with even adjusting ip parameter.
Handling of VPN parameter is unrealistic.

After analyses of a dozen of open source VPN solutions, tinc is best for
this and runs on many platforms. When the user has authenticated itself,
the tinc gui sends its just created pub key and gets the pub key from
the other side (config server) with ip paramter together. Then the files
get written und tincd service gets startet.

I understand, i must do something about the parameter exchange
integrity.

Would this be sufficient? :

A pool of pgp keys. The public part of the keys static in
the client software. Use 1 good privkey of that pool to sign the
working tinc pubkey on server side. On request transport pubkey
to client over the wire, let client verify the key. All further
exchanges on the wire are signed with the tinc working server side
privkey. Content from server is signed directly from server.
Content from client is first send to server, then signed, transported
back, verifyed.

This is some kind of 3 party key exchange. I just do not have the
knowledge to do x509. Using gnupg sounds clearer to me.


G. Axel