On Wed, 6 Jun 2001, Jose Nazario wrote:
> sure they can. SSL, IPSec, etc .. all of those can force client side
> authentication, not simply setup procedures.
That's a keying property though, not a tunnel property. IOW: there's
nothing in the "tunnelness" that mandates auth, and there's nothing about
the tunnel that makes a particular mechanism "strong," since it's all
about key management, and weakly managed keys don't equal strong
authentication. Add to that the typical failing of ensuring a strong
encryption boundary on the client (What? Not allow Web access while in a
tunnel?) and it rolls downhill pretty quickly. Deploy it on 9x where the
keys are available to all comers and it's dismal.
IOW, the same authentication could be done in an application, encrypting
the tunnel provides some confidentiality and integrity, but doesn't force
the issue, since it's still possible to make a weak implementation of the
tunnel that does that so poorly that it doesn't matter.
> you seem to forget this. you seem to think that its an open ended pipe.
No, what I do realize is that in the non-MLS arena and especially in the
"trusted machine on an untrused OS with a non-security savvy user" realm,
to truly do good trust and flow management creates a schema so complex
that nobody will do it in the real world.
Look at the issues that companies have to deal with when a
communications/network person leaves as far as locking down remote access,
then extend that out to a group of potential trustees that's in the 20% of
the company range. Add in administrative overhead, testing and
verification, etc. and it gets ugly and expensive.
> > 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.
>
> a decent scheme can significantly reduce the risk of a malicious
> application impersonating the client, through various combinations of
> authentication.
Not if the application was written to tunnel over the legitimate client's
data stream. Also, adding authentication layers becomes problematic for
end-users and diagnostic staff. Aren't password issues still the #1 IT
cost issue? Adding "can't be automated, has to be that human"
authentication is more costly than most people think and doesn't extend
well to a lot of protocols and applications. Most implementors don't even
bother with that though- putting us back to the good old reusable password
schema.
> an actually axent has a product for their VPN client that monitors
> external access to the machine aside from the other endpoint of the VPN.
> so, to the best of my knowledge, but that's a start. that's been a concern
> of mine back in my consuting days, and the axent product was worth looking
> at for me.
There are starting to be products that do connection management, but that
doesn't necessarily equate to much on an untrusted OS (like say Win98) and
doesn't fully address the trojan issue, though it does take care of things
like route.exe. It's not that difficult to write something that will shim
under the driver and take all commers. In a targeted attack, it's not
that difficult to get installed either. Home-based VPN users are primo
social engineering targets. Add in a channel like HTTPS, which is always
enabled and always allowed and things get ugly even faster. I sure
wouldn't deploy anything that didn't allow connection management though,
it's definitely a big step in the right direction.
> > as for other aplications hijacking the tunnel, or use of it, you seem
> again to forget the use of firewalls *after* the traffic has emerged from
> the other endpoint of the tunnel.
As we've discussed, that's only possible if the traffic is decrypted at a
point that's inspectable. Remote control over SSL to a desktop, for
instance isn't all that firewallable. Virus/worm outbreaks seem to be
leading indicators to me of the ability of large organizations to stop
end-users from creating tunneling opportunities- and that picture doesn't
look good, especially when you look at the fact that the protection
mechanism is based on global, not targeted attacks. It's also only
possible if the illegitimate traffic is not exploiting the same vector as
the legitimate traffic. That's increasingly less useful as we get more
and more information into easily accessable systems.
In the case of B2B partnerships, both ends need equal protection, which
makes things more difficult. Even the VPN poster child, the ANX is done
over a private network.
> > VPNs are sold as security solutions when in reality they're trust
> > boundary weakeners- if you understand their limitations, then
> > deploying them isn't as much of an issue as if you don't understand
> > that key point and go happily extending trust to every employee and
> > business partner's own private networks with their own weak and weaker
> > trust boundaries.
>
> you seem to be presenting a VPN as this pipe that will allow anything in
> on either end. while a poorly configure VPN can indeed do this, and
> protect the content form external inspection as you note, even a modestly
> correctly configured one isn't just a funnel to suck traffic in and shove
> it down the pipe to the corporation, through the firewall.
I took a serious swag at a trust model for a VPN-enabled enterprise with
~40k employees that would allow remote access to critical infrastructure
with limited excess trust extension for ~200 sites. By the time I got to
the identification of critical resources and who could access them from
where part, I had serious doubts- when I got down to the "moves, changes,
additions, deletions" part for people and equipment, I decided that I had
better things to do...
> i will grant you that you're poiting out considerations often overlooked
> when people decide to implement VPNs, but, like i said, i think you
> overlooked a number of things.
In a past life, I used to extend extremely important networks into places
like hotel rooms in foreign countries with what I'd consider to be a
credible hostile threat level. I've pretty much done the encryption and
tunnel thing about as well as it can be done. I've also looked at a fair
ammount of malicious code in the intervening years, including tunneling
stuff, and I've written non-malicious code that's tunneled data over
channels like DNS. When you get outside of per-service tunnels with
reasonably high assurance on the endpoints things can be made to fail
pretty spectacularly. In the last tunnel over DNS thing I did, a
grand total of 2 people detected the tunnel and asked about it, and
several hundred people ran the code.
Could Microsoft have stopped the particular source code leak they had with
one of three or four easy things? Sure, absolutely they could have.
Could they reasonably secure that vector from a targeted attack? That's
significatnly more doubtful.
> anyhow, hope this clarifies my take on things,
It does, I obviously enjoy spirited debate, and as I said, the audience
and space limitations stopped some further explorations and explainations.
One day I'll do my entire VPN rant in a paper- it's related, but not 1:1
to the tunnel rant.
Despite all that, my major issue isn't necessarily the weakend extension
of trust, it's more the fact that people don't understand that they're
doing it, or how easy trojans are to write, and they're building
infrastructure on swampland.
Thanks,
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
