3 ms·

One use case is to allow secure authentication. For example, some software, such as VPN clients, will now open the authentication page in a Chrome/Firefox web

by johnmaguire2013 6y ago

One use case is to allow secure authentication. For example, some software, such as VPN clients, will now open the authentication page in a Chrome/Firefox web browser, rather than in an embedded browser - this is a security win! It affords the ability to use WebAuthn/U2F, password managers, as well as an updated browser. However, for this to work, you need to pass an authentication token back to the client - this is done by binding to a port locally, and exposing a webserver which receives an authentication token. Duo Network Gateway[1] authenticates this way, and I'm sure others do as well. I know Palo Alto GlobalProtect, AWS CLI, and others offer web-based authentication now, but don't know specifics of their implementation. (I work at Duo.) [1] https://duo.com/docs/dng#ssh-servers-diagram https://duo.com/docs/dng#ssh-servers-diagram

est31 6y ago
Interesting points, thank you. The cloud service could communicate with the local device's client through a separate connection though that the client opens with that cloud service, no need to do this via the local JS. The only benefit I could think of would be that it makes it easier to correlate the local client with the authenticating user, but you could just have a token that you make part of the URL the client visits. Also it doesnt fully solve the correlation problem either, on the same computer, two clients could run under two different OS level accounts. Will it just send its authentication token to one of those clients? There is no user separation on Windows or Linux. I only know about Chrome OS having user separation at the port level.
- johnmaguire2013 6y ago
  > Also it doesnt fully solve the correlation problem either, on the same computer, two clients could run under two different OS level accounts. Will it just send its authentication token to one of those clients? When the request is made to the server, the port that is temporarily bound is also sent with the request. This tells the server what URL they should POST back to. The port is random for each authentication. > The cloud service could communicate with the local device's client through a separate connection though that the client opens with that cloud service, no need to do this via the local JS. FWIW, no Javascript necessary. Just a regular POST form & Location headers. In any case, you're right - you could open up a separate connection to the server with a correlation ID, and include the same correlation ID in the initial request to the authentication server, and then upgrade the connection's permissions after the fact. You ought to be careful of session fixation attacks here. (Attacker can send Victim a link, and when Victim authenticates, Attacker is logged in. With a local web server receiving the token, when Victim authenticates, they see an error instead.) As always, there's engineering tradeoffs in building different solutions. Some factors (besides concerns around session fixation) that may come into play: - Typically, the authentication and authorization step occurs prior to opening a tunnel or long-lived connection. Shifting when this occurs can have unexpected or unwanted side effects. In the case of the DNG, which protects web applications in addition to SSH servers, authentication is typically provided via cookies, and so the tunnel opened for SSH is actually a sort of Websocket connection. With the approach I have described, authentication occurs prior to upgrading the HTTP request into a Websocket, in the same manner it does for web applications. In the approach you suggest, this would have to flip a bit, meaning re-implementing authentication inside the Websocket connection itself. - What if the authentication server is not the service provider? For example, in the SAML ECP profile, the client negotiates an authentication token from the authentication server on behalf of the service provider. It then takes this token back to the service provider for cryptographic verification. You could instead teach the authentication server how to talk to the service provider directly (e.g. the HTTP-Artifact protocol) - but this works better if you own both the IdP and the SP. In many cases, customers may bring their own identity provider (e.g. Okta) with them to the service provider (e.g. GlobalProtect.)

est31 6y ago

Interesting points, thank you. The cloud service could communicate with the local device's client through a separate connection though that the client opens with that cloud service, no need to do this via the local JS. The only benefit I could think of would be that it makes it easier to correlate the local client with the authenticating user, but you could just have a token that you make part of the URL the client visits. Also it doesnt fully solve the correlation problem either, on the same computer, two clients could run under two different OS level accounts. Will it just send its authentication token to one of those clients? There is no user separation on Windows or Linux. I only know about Chrome OS having user separation at the port level.

johnmaguire2013 6y ago
> Also it doesnt fully solve the correlation problem either, on the same computer, two clients could run under two different OS level accounts. Will it just send its authentication token to one of those clients? When the request is made to the server, the port that is temporarily bound is also sent with the request. This tells the server what URL they should POST back to. The port is random for each authentication. > The cloud service could communicate with the local device's client through a separate connection though that the client opens with that cloud service, no need to do this via the local JS. FWIW, no Javascript necessary. Just a regular POST form & Location headers. In any case, you're right - you could open up a separate connection to the server with a correlation ID, and include the same correlation ID in the initial request to the authentication server, and then upgrade the connection's permissions after the fact. You ought to be careful of session fixation attacks here. (Attacker can send Victim a link, and when Victim authenticates, Attacker is logged in. With a local web server receiving the token, when Victim authenticates, they see an error instead.) As always, there's engineering tradeoffs in building different solutions. Some factors (besides concerns around session fixation) that may come into play: - Typically, the authentication and authorization step occurs prior to opening a tunnel or long-lived connection. Shifting when this occurs can have unexpected or unwanted side effects. In the case of the DNG, which protects web applications in addition to SSH servers, authentication is typically provided via cookies, and so the tunnel opened for SSH is actually a sort of Websocket connection. With the approach I have described, authentication occurs prior to upgrading the HTTP request into a Websocket, in the same manner it does for web applications. In the approach you suggest, this would have to flip a bit, meaning re-implementing authentication inside the Websocket connection itself. - What if the authentication server is not the service provider? For example, in the SAML ECP profile, the client negotiates an authentication token from the authentication server on behalf of the service provider. It then takes this token back to the service provider for cryptographic verification. You could instead teach the authentication server how to talk to the service provider directly (e.g. the HTTP-Artifact protocol) - but this works better if you own both the IdP and the SP. In many cases, customers may bring their own identity provider (e.g. Okta) with them to the service provider (e.g. GlobalProtect.)