[HN Gopher] Show HN: Wag, MFA and Enrollment for WireGuard
___________________________________________________________________
Show HN: Wag, MFA and Enrollment for WireGuard
Howdy folk, I've been building this project as both a side project
and my job for a little while now. The rationale behind it is while
wireguard is a fantastic protocol cryptographically it leaves a lot
to be desired when it comes to enrollment and end user device
security. Obviously instead of using an off the shelf solution
like tailscale, I decided to reinvent the wheel which has honestly
been quite fun with learning about eBPF, and recently clustering
and HA with etcd! The most recent version (in the docker
container) contains about 6 months of very new work bringing it all
from sqlite3 to etcd. So please be forgiving if it does some weird
things! Hope you all enjoy! P.s Im not a web developer and any
tips on that front to make it less teeth pullingly awful are
welcome!
Author : Nullence
Score : 112 points
Date : 2024-05-11 07:31 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mahkoh wrote:
| >IPv4 only.
|
| You'd think that sites choosing wireguard would have a more
| modern setup and might make heavy use of (self service) ULAs.
| tptacek wrote:
| What are the ULA wins you're thinking of here?
| d-z-m wrote:
| Do you protect against bruteforcing the TOTP code? I.e. via rate-
| limiting or a set amount of retries? I took a quick glance at the
| code and couldn't find anything to this effect.
|
| The scenario I'm imagining is: someone opens the TOTP entry UI in
| their browser, opens devtools, and starts to loop through all
| possible TOTP codes.
| Avicebron wrote:
| I can't speak to the specifics of this particular
| implementation but usually if someone has the login (username +
| password) to get to totp that user has already been
| compromised..
| asimops wrote:
| But MFA is there to prevent this compromise from affecting
| the service and alert users/admins to the compromise, right?
|
| If you have username and password and are able to force the
| TOTP in the 60s window, the TOTP would be useless imho.
| yonatan8070 wrote:
| If a user keeps their credentials in a notebook and it got
| stolen, the TOTP check can be the difference between the
| attacker getting in, and the user being notified and changing
| their password
| yardstick wrote:
| Unfortunately these days it's even easier with password
| managers containing all three (user, pass, token)
| ThePowerOfFuet wrote:
| The difference being the notebook is paper and easily
| read, while the password manager is... quite a bit
| harder.
| 8organicbits wrote:
| I think thats here:
|
| https://github.com/NHAS/wag/blob/cdbdbec3393fa86bf6c823117c8...
| asimops wrote:
| Have you tackled the issue of session management or are you
| planning to do so? Essentially wireguard key are just eternal
| session keys.
|
| I would expect software that implements the wireguard transport
| layer to implement session management to be called a working VPN
| server solution. This means a second channel to the server for
| periodically rotating session keys, terminating sessions,
| changing IP addresses, configuring new routes and repeating
| authentication if necessary.
| Aloha wrote:
| It seems to me that if I were building a VPN client like Global
| Protect but using WG, I'd have an eternal per client auth key
| that is used to set up an initial tunnel to the VPN controller,
| over that you perform auth, etc, then you're given another
| session key, which is valid as long as that session is. The
| first tunnel would disconnect as soon as you finished
| authenticating and got your actual session key.
| mbreese wrote:
| Why even have the first tunnel? You could do the entire thing
| out of hand over a web interface or other mechanism. If the
| public address of the WG server (or the authn server) is
| known and available, then there's no real difference in
| setting up the connection over a persistent WG channel vs an
| HTTPS service.
|
| Both solutions are custom for that VPN, so I'd just have one
| WG tunnel that's controlled through a secured (web)service.
| The bonus is that you wouldn't need a hard coded initial key.
| (You'd still need some authentication mechanism, but it could
| be more than fixed public/private key pairs).
| gchamonlive wrote:
| I'd use firezone for that. It has an option that forces the
| user to login to the platform regularly. Coupling that with an
| external identity provider via oidc is a very solid and simple
| solution for session management.
| ta1243 wrote:
| This looks nice, but a couple of things
|
| > curl
| http://public.server.address:8080/register_device?key=e83253...
|
| > The service will return a fully templated response
|
| It looks like the "registration" involves the server generating a
| private key then sending to the client, rather than the client
| generating a private key and sending the public key to the
| server.
|
| Not only that but your example is http! Probably worth replacing
| that part at least in case people think http is a reasonable
| option.
|
| > To authenticate the user should browse to the servers vpn
| address, in the example, case 192.168.1.1:8080, where they will
| be prompted for their 2fa code.
|
| So when the session times out, is there any way for the client to
| realise this? Or does their ssh session (or whatever) just stop
| working?
|
| I've on and off looked for a wireguard client which can do
| something like the captive portal detection on wifi. Ideally it
| would be an extra line in the config file (like
| persistentkeepalive), which does a URL pull. Could be checked
| periodically (like with the keepalive). If it returns "OK", then
| fine, if it doesn't return then there's a network problem, but if
| it returns a "Location" header, the client would pop up a browser
| at that location, allowing for session reauthentication or
| whatever.
|
| I haven't found one.
| 20after4 wrote:
| > I've on and off looked for a wireguard client which can do
| something like the captive portal detection on wifi. Ideally it
| would be an extra line in the config file (like
| persistentkeepalive), which does a URL pull. Could be checked
| periodically (like with the keepalive). If it returns "OK",
| then fine, if it doesn't return then there's a network problem,
| but if it returns a "Location" header, the client would pop up
| a browser at that location, allowing for session
| reauthentication or whatever.
|
| That would be really cool. I hope the author of this will
| consider it.
___________________________________________________________________
(page generated 2024-05-11 23:00 UTC)