mjr writes:
>Rick Smith writes:
>>I'd argue that the best way to deal with firewalls is to design a
>>transaction protocol around messages that can be relayed. In other
>
> Yes!!
> One of the frustrating realizations I've been having in the last year is
>that the single BEST thing we could do to improve Internet security would be
>to (hold onto your seats!) toss out the current set of user-level IP
>applications and rebuild new ones that provide a TLI-like socket abstraction
>that maintains a credential-based, authenticated, possibly encrypted,
>tamperproof session. The applications wouldn't have to be aware of it other
>than being able to reach into the abstraction layer and pull out *reliable*
>information about who was on the other end of the connection, based on some
>kind of asymmetric certificate.
> If that kind of capability were in place, we could make a *HUGE* amount
>of ugliness go away. No more FTP, just use "rcp". No more passwords over the
>'net, essentially you'd get free single-signon. No more firewalls,
>applications would be able to make the kinds of policy decisions firewalls
>make today.
> It's tough to describe the entire concept in Email and it's probably not
>worth it since we're wrapped too tightly around the axle of backwards
>compatibility. To me, it's a shame that we're going to have IPV6 eventually,
>and we'll still have FTP with all its warts and design flaws. Rather than
>scrapping and rewriting 20 or so key applications so that they provide
>portable cross-platform security, we'll add all manner of kruft to the
>protocol stack. And call it "progress."
The examples you quote dont take into account the problems of alternative
access into a network. If a black-hat (aren't the NSA called this too? :) were
to intrude into your networks via your dialups, x25 links, hijacked sessions,
or plain social engineering then the lack of authorization you suggest will
allow Morris worm-like breeding. I'm still exploring the TLI concepts
suggested above, I can see real value in them, but I have seen TLI attacks
too that make me very paranoid about authorising their usage.
I suspect you are describing a utopian picture where all access is controlled
by automagic reliable access control and that every method of access has the
mechanisms to enable such streams. To me this is only half of the problem,
the other half being to implment the adage of something you have, something
you know. In my view it is reasonable to enforce the challenging of all net
related activity, i.e. asking for a password/challenge response even if you
are happily sitting inside an encrypted stream. Not something that can be
automated but always requires human input. This is not practical for all
instances and I see that as a risk, a very real one.
In short, you might have a safe virtual network, but if and when that is
compromised, it's like the internet of the early 80's (fun + open:). Every
defense I can come up with can also be countered with an direct attack or
one on a tangent. The best that you can hope for is to raise the level of
expertise needed by covering as many bases as you can and making the effort
involved in breaking in too much to be worthwhile. The openess you suggest
above may be acceptable for some applications but it seems like two steps
backwards where security is concerned.
Cheers,
Mark
References:
|
|
