Le 13 septembre 2019 à 14:49:31, Nico Schottelius ([email protected](mailto:[email protected])) a écrit:
> > Hey Rémi, > > that is very welcome news. We might actually also be interested in > this. Are you by any change using pyotp for your server? Hi Nico, yes pyotp is the implementation I use on the server, but anything Compatible with rfc6238 should work. > We have written ungleich-otp [0] that extends the otp approach with > realms similar to kerberos. This looks interesting, I will move the code that validate the OTP in a separate class so that another validation backend like one based on this project can be used instead of reading the seeds from a SQLite file like I’m doing now. I did not see any kind of cool down in https://code.ungleich.ch/ungleich-public/ungleich-otp/blob/master/otpauth/serializer.py. Are you not worried that someone could try to brute-force the OTP validation? > In regard to faking the address: given that there are no other routes / > servers in your network that can send traffic *from* that particular IP > range, your assumption should hold. Thanks :) > Best, > > Nico > > [0] https://code.ungleich.ch/ungleich-public/ungleich-otp > > Rémi Lapeyre writes: > > > Hi everybody! We are using WireeGuard on Mac and Linux which works great > > but for > > compliance purpose, we would like to be able to add an OTP challenge on > > connection. > > > > I've been looking at the archive of the mailing list and at the various > > projects > > built around WireGuard and started writing an implementation based on the > > idea > > from https://lists.zx2c4.com/pipermail/wireguard/2017-September/001741.html: > > > >> Alternatively, you could do OTP in-band, in order to authorize that > >> public key for a certain window of time before inactivity. In this > >> scheme, you'd disallow access to the network segment based on firewall > >> rules until a certain in-band challenge is made -- perhaps by > >> contacting a certain sandboxed server and answering an OTP challenge > >> there > > > > My current implementation (I plan to publish it under MIT license once it's > > ready) has a Python server on the WireGuard server bound to the wg interface > > that add an IPTable rule to allow the traffic for a given amount of time > > when > > a TOTP is received over TCP. Here are some details > > > > - The TOTP is bound to the internal tunnel IP address so the IP address > > that > > opens the TCP connection is used to identify the user, as thee packet > > must > > have been decrypted, it seems to me that there is no way to spoof this. > > > > - A small text protocol let the user log-in, log-out and read the status > > of the > > connection. > > > > The client needs to send the TOTP just after connecting to the server, for > > which > > I had hoped to use the "PostUp" field of wg-quick. > > > > {Post,Pre}-{Up,Down} seems to be only available on wg-quick for now but we > > are > > using the wireguard-apple client so I have a few questions: > > > > 1. Is the absence of support {Post,Pre}-{Up,Down} in wireguard-apple on > > purpose or would a patch to add this welcomed? > > > > 2. Is this way to do the OTP authentication sound? > > > > 3. I've seen that TunSafe has added an extension to the WireGuard > > protocol so > > the TOTP auth would not be shared by an attacker that succeded to connect > > when > > the user is already connected. This seems like a good idea to do, what > > are your > > thougts about this? Would you recommend against my "easier" > > implementation? > > > > 4. I know that TunSafe was strongly advised against when it was > > closed-source. > > Now that it is AGPL code, is it still the case? > > > > One more thing, to simplify the deployment of WireGuard, I would like to > > propose > > a change in the way the MacOS client import WireGuard configurations from a > > file. > > > > Our current flow is "Please open the WireGuard app, click on create Tunnel, > > give > > it a name, paste this configuration underneath what's already written, hit > > save > > and send us your public key". It gives a lot of oportunity to the user to > > mistype something and make changing the configuration cumbersome ("Edit the > > tunnel, don't touch the `[Interface]` part but replace what's underneath by > > this") so I would like to be able to send to the user a configuration file > > with > > the PrivateKey missing and have the WireGuard client generate one on the > > fly but > > this currently gives an error "Interface’s private key is required". Would > > sending a patch for this be welcomed too? > > > > > > Thanks for taking the time to help me, I look forward to contribute to > > WireGuard :) > > > > Rémi > > _______________________________________________ > > WireGuard mailing list > > [email protected] > > https://lists.zx2c4.com/mailman/listinfo/wireguard > > > -- > Your Swiss, Open Source and IPv6 Virtual Machine. Now on > www.datacenterlight.ch. _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
