On 6 Jun 2001, at 20:41, Paul D. Robertson wrote: > On Thu, 7 Jun 2001, Ben Nagy wrote: > > > > Nothing on the market currently prevents a malicious client > > > from being the > > > source of authentication, and that's the biggest tunnel issue > > > out there-- > > > the "Microsoft source code out the window" stuff. > > > > I take it you're talking about Joe Luser VPN'ing in to work when his PC is > > already r00ted by some trojan, or similar circumstances? I've seen at least > > It's true not just of VPN tunnels, but yes, that is probably the > predominantly hanging vector. > > > one client (Cisco - the old SafeNet one) that can chop off all other traffic > > if a VPN connection is up. That doesn't prevent time-bombs, but it does > > I proposed this as a fix at an NISSC panel discussion on VPNs I > particpated in back in '98. Back then I think it was potentially valid- > but now-a-days I'm thinking it's actually less useful than it would > appear... > > The problem is that everyone seems to _require_ HTTP/HTTPS access these > days, so there's your trojan's control vector happily provided either > directly, or via the corporate firewall. And this is different from an on-site user, visiting the web through the corporate firewall, exactly HOW? i.e. I do not see how this risk is exacerbated if the client connection comes across a VPN tunnel rather than just a length of Cat5. [Consider also the case of the travelling employee who, after a stint on the road, plugs his laptop into the internal net. No amount of filtering at the tunnel endpoint is going to address this analogous real-world case where a machine is sometimes connected to the internal net, and sometimes not.] David Gillett - [To unsubscribe, send mail to majordomo@lists.gnac.net with "unsubscribe firewalls" in the body of the message.]