mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 10:18:54 +00:00
c581439ee2
Based on testing and research it does not appear that Chrome will reliably choose a consistent protocol stack for loading the initial web page as it does for connecting the WebSocket when connecting over VPN tunnels. If one or the other stacks experiences a slight delay or packet loss causing retransmission, or QUIC simply doesn't play nicely with the MTU (in our case 1280), it may fall back to IPv4 (which has less per-packet overhead) or even a TCP connection. Unfortunately this violates an assumption we have in token validation logic. Namely, that the remote_ip used to create the token (via sign in) is the same one used to the connect the WebSocket. I can see where this logic comes from in a security context, but thinking through the attack vector(s) that would be able to leverage this violation has me left wondering if this check is worth the breakage we currently face in #6511. - Scenario 1: MITM - attacker steals token somehow via MITM (would need to somehow break TLS) - the attacker is already in our network path and can rewrite the remote_ip already with his/her own. - Scenario 2: Malicious browser plugin stealing session token. It will be harder to spoof the remote IP in this case, but if this is a possibility, the plugin could presumably directly control the tab where the user is logged in. - Scenario 3: IdP is compromised leading to malicious redirect before arriving to Firezone - if this is the case, the user could likely login in directly and create his/her own valid session token anyhow. Perhaps I'm missing other scenarios, open to feedback. If we want to ensure the token used by the websocket originated from the same browser as it was minted from, perhaps we could generate a small random key, save it in local storage, and send that in a header when connecting the WebSocket. I think cookies handle that for us already though. Fixes #6511