You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Chrome 85 broke our ability to use the nassh-relay. Here's how:
We must first authenticate to an "inbound HTTPS proxy", which sets a domain-wide cookie
Because the Chrome SSH proxy is an extension, WebSocket requests originating from the extension are prevented by the new (as of Chrome 85) same-site cookie policy. The "inbound HTTPS proxy" then posts a 302 redirect to the authentication page: 302 causes the WebSocket request to fail (the user is not presented the login page).
I was able to work around this by posting a static HTML page that re-issues the cookie with samesite=none, and this fixes the problem. Users must visit a magic web page after authenticating but before trying to SSH.
It might be possible to have nassh-relay also re-issue the cookie, which would be a nicer user experience. I would be happy to provide the name of the cookie in an argument to the program. This would probably have to show up in JavaScript, in case the "inbound HTTPS proxy" strips the cookie from the request before passing it along.
This would probably require some way to provide nassh-relay with the cookie to be re-issued, and may require the /cookie handler to reply with JavaScript which reissues the cookie performs a redirect, if it is currently sending an HTTP redirect.
If this sounds like a reasonable approach, I will attempt to dust off my Java knowledge enough to submit a patch.
The text was updated successfully, but these errors were encountered:
For my purposes, what is going to work best is to re-issue every cookie the browser sends to /cookie for path=/connect.
I need to test it, but I think this will work, if added to line 77 of CookieHandler.java:
// Re-issue all cookies request.cookieMap().forEach((k,cookie)->{
cookie.setSameSite(CookieSameSite.NONE);
cookie.setPath("/connect");
response.addCookie(cookie);
});
If this solves my problem, I'll try to add a commandline option to enable it. It's going to be another week, at least, but I'll get there :)
Chrome 85 broke our ability to use the nassh-relay. Here's how:
We must first authenticate to an "inbound HTTPS proxy", which sets a domain-wide cookie
Because the Chrome SSH proxy is an extension, WebSocket requests originating from the extension are prevented by the new (as of Chrome 85) same-site cookie policy. The "inbound HTTPS proxy" then posts a 302 redirect to the authentication page: 302 causes the WebSocket request to fail (the user is not presented the login page).
I was able to work around this by posting a static HTML page that re-issues the cookie with
samesite=none
, and this fixes the problem. Users must visit a magic web page after authenticating but before trying to SSH.It might be possible to have nassh-relay also re-issue the cookie, which would be a nicer user experience. I would be happy to provide the name of the cookie in an argument to the program. This would probably have to show up in JavaScript, in case the "inbound HTTPS proxy" strips the cookie from the request before passing it along.
This would probably require some way to provide nassh-relay with the cookie to be re-issued, and may require the
/cookie
handler to reply with JavaScript which reissues the cookie performs a redirect, if it is currently sending an HTTP redirect.If this sounds like a reasonable approach, I will attempt to dust off my Java knowledge enough to submit a patch.
The text was updated successfully, but these errors were encountered: