Closed paulb-smartit closed 1 year ago
Unfortunately this is quite hard to fix, the way wag works is that it constantly monitors the real world endpoint (ip & port) of the device and uses that its primary identity metric.
The reason for this is it prevents an attacker who has cloned the wireguard configuration from a device from being able to successfully "step in" on a clients session. I.e if a client authorises, the attacker with the same private key cannot start sending traffic to internal secure VPN resources.
I have been asked for a feature that would keep an authorisation cookie in the web browser that would allow people to either refresh the page without having to re-enter credentials or to have a constant websocket connection that continually refreshes authorisation.
However Im not sure how well this would work for say a mobile device and it also become a concern that an attacker would be able to step in on a connection, as there would be no real in-web-browser way of identifying a good user roam, vs an attacker assuming the connection.
I'll have a think about it. But unfortunately I think this may be marked as "cant fix" as detecting and responding to these types of events are already painful with wireguard, and making the distinction between friend and foe is virtually not possible.
I'm not expecting miracles, as I can't think of a reliable method of storing a cookie on the user device to manage this at all. The closest I get is using a post-up process to somehow prove a session existed. But then isn't post-up fired only at the initial WireGuard up, and not on reconnects?
Reverting to only private key auth answers the question, but at the cost of security.
In the past, the answer has been multiplexed ssh connections, which does work well. But it brings in the use of socks proxies, browser complications, and networking difficulties that users complain about anyway.
Grateful for any thoughts at all on this.
Yeah. While wireguard itself is designed to roam, wag is trying to make it not roam, or at least not roam aggressively. There isnt any other way to tie the user identity to the sending external address.
From what you're describing you'd probably have to have some sort of wag agent. Which I am about 80% against, primarily because I dont really want to install anything more than wireguard-tools on a client device.
The best thing I can think of is that on successful authorisation the service could issue a cookie to the client web browser that if sent to the authorisation page will just refresh the auth. Rather than having to type the code in again
Having no "wag agent" is a good thing.
Sad to say, this is becoming a showstopper for us, because of 1 user who works on the train - occasionally.
I've advised they can continue with OTP on ssh and carry on with socks proxying, but "end users ..." ;)
With an OAuth implementation, will the connection stay valid due to the back channel and auth token?
Well sorry to hear that, the connection wont stay valid if people are moving about a bunch as I havent built in using the back channel to do anything like that as of yet.
A potential solution is to have the "success" page open a persistent websocket connection that continually reauthorized the connection.
Could you give me some indication about how quickly they're de-authorized?
Well, that's the thing. They aren't actually using it, just coming up with objections.
I'm certainly not giving up, as the benefits for the many far outweigh an edge case.
The primary objections seem to revolve around
I did rethink what I said about OAuth and the token. As I realise that wouldn't happen without an agent or browser, staying open.
Wondered if there was some systemd / udev magic I could use that launches a browser when a network event happens, eg. on curl response to otp or the like.
Yep you definitely could do something with systemd, or just with a background job that just asks the vpn, and if it doesnt get the success screen then it pops up stuff.
(If you ask real nicely I can just make an endpoint such as /authenticated
that would return true or false, orrrrr even better make it a websocket and push a notification out when you're deauthed)
Pretty please?
The push on deauth wouldn't work though as you're likely to have lost the connection?
Maybe /status
and return other goodies about the connection?
Sure /status
it is, I think for the moment I'll make it just a GET request, as the oidc stuff is quite big and requiring a lot of brain.
Just getting us back on the glibc train with a dockerfile builder that targets debian 11, and thus glibc 2.31+
No need to go way out here. GET should be fine. If I knew go
I'd try to be more helpful.
For us the client end, a simple bit of python or perl will probably be the quick answer.
Definitely gonna leave it up to everyones creative imagination as to what they do with the endpoint.
I've just release v2.0.2 which is built with debian 11, so your glibc problems should be over now.
Howdy @paulb-opusvl, is this still a blocker for you guys?
Howdy @paulb-opusvl, is this still a blocker for you guys?
Sorry, been distracted with the day job. It was never a blocker (for more than one user) :) I haven't upgraded in a while and people are using it. I've seen no complaints other than the usual "why do I have to keep typing in a stupid number?"
I'll probably fire up a new instance to test out a newer version.
Hopefully with the newer version thatll become "why do I have to tap a blinking light on a USB" instead.
Or whatever your sso option is :p
If this isn't a problem so much feel free to close it and reopen it if it becomes a pain
Closing
If a user is using 3rd party wifi/4G etc. when they roam between points and get a new connection they will be seen as a new connection. This will cause a need to revisit the OTP page to reauth. I have a few users who see this as an issue.
Is there any thought you have toward maintaining authentication between roaming changes?