public inbox for govpn-devel@lists.cypherpunks.ru
Atom feed
From: Sergey Matveev <stargrave@stargrave•org>
To: govpn-devel@lists.cypherpunks.ru
Subject: Re: [Govpn-devel] Invalid server's random number
Date: Wed, 19 Oct 2016 22:45:46 +0300 [thread overview]
Message-ID: <20161019194546.GA2651@stargrave.org> (raw)
In-Reply-To: <97529953-7039-473E-BB4E-8C710C5BF966@robotinfra.com>
[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]
Greetings!
*** Bruno Clermont <bruno@robotinfra•com> [2016-10-19 19:25]:
>handshake.go:290: Invalid server's random number with $PEER
>I did my homework, even spent some time trying to figure why looking at the code. But that function is quite cryptic to me. So, what this error mean? What cause this? How to fix?
http://www.govpn.info/Handshake.html
Second message, that is sent from server to client, contains randomly
generated RS (Random number of Server), that is sent enciphered to the
client. Client have to decrypt it and send back to the server in third
encrypted message -- confirming that second message was deciphered
successfully and that he really received it from the server exactly
during that session. Server checks that received RS equals to the saved
in Handshake.rServer one.
Actually I have never seen this part failing. In theory that means that
your handshake packet was tampered, man-in-the-middle changed their
contents. But in practice I can not assume what is going wrong (if no
traffic is really tampered).
Do you have equal GoVPN versions (6.0 on both sides)?
Are you using amd64, 64-bit platform?
If you run tcpdump and listen for the traffic on GoVPN's port, is there
really only three packets are passed between (C->S, S->C, C->S)?
Be sure that all your configuration on the client and server side is
equal! For example if you enable "-encless" mode just on one side --
nothing will works, if you enable -noise/-cpr/etc options -- nothing
will works too. You have to use symmetrically equal configuration
options on both sides. GoVPN has very simple protocol without any
options and configuration agreement/coordination (this is an additional
possible attack vector).
If everything is ok there (try to setup all configuration from the
ground, from very beginning), then personally I will add debugging
print-s in the code to see are encryption keys, nonces and deciphered
information is the same on both sides and when it becomes different.
>Bonus question: could it be very hard to add support for tun interface instead of tap?
"instead of" -- no, "in addition to" -- seems to be yes :-)
I have never worked with TUN interfaces, but seems that working with
them is the same as with TAP ones. Just slightly another structures.
So should be relatively easy. I added TUN support to the TODO list, but
currently can give no time expectations when it will be done (to much
work now :-().
--
Happy hacking
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2016-10-19 19:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-19 16:05 [Govpn-devel] Invalid server's random number Bruno Clermont
2016-10-19 16:57 ` Bruno Clermont
2016-10-19 19:45 ` Sergey Matveev
2016-10-19 19:45 ` Sergey Matveev [this message]
2016-10-20 13:27 ` Bruno Clermont
2016-10-20 19:36 ` Sergey Matveev
2016-10-29 18:05 ` [Govpn-devel] TUN interfaces (was: Invalid server's random number) Sergey Matveev
2016-10-29 18:12 ` Bruno Clermont
-- strict thread matches above, loose matches on Subject: below --
2017-03-01 15:54 [govpn-devel] Invalid server's random number Le Blanc
2017-03-01 20:36 ` Sergey Matveev
2016-10-19 16:00 [Govpn-devel] " Bruno Clermont