[dspillett]

> You basically have to trust everyone on the remote LAN to not

More than that when connecting via WiFi as almost everyone on a laptop does these days: you have to be careful of “evil twin” attacks from random APs nearby.

Though if you are accessing a VPN to get access to internal network resources, and someone uses this hack to redirect you, you are not going to see those resources anyway and you'll know something is wrong. Accessing any insecure resources is a risk (HTTP traffic can be monitored, fake servers could collect authentication credentials such as SSH user+pass info if not using key-based auth) but only if they are otherwise public because your redirected connection won't be able to route to your corporate network's internal hosts.

Unless I'm misreading (possible, I've only skimmed the details) those using VPNs because they already don't trust their outgoing connection, or are otherwise wanting to disguise their ID and/or location, are more at risk than road-worriers (or these days “home warriors” more likely) connecting to DayJob's VPN.

[djbusby]

When I connect on SSH it verify the host-key. So, that would warn before submitting user/pass (but also, user-key should be used)

[dspillett]

If doing SSH properly, yes.

Though for new hosts people often don't verify the initial host key at all, just blindly accepting it, so that would be an extra risk vector.

Heck, I'm sure many don't bother verifying a new key when they get the warning, instead just removing the old from .ssh/known_hosts (or equivalent) to quiet the complaining! Though to be honest, with that security posture nothing is going to save them and our efforts are better spent securing others! I know at least one of our clients has automated systems that ignore key changes, because we once had a temporary config cockup that sent some connections to a host with the wrong key and some data was received there without any reported issues…