Stewart Stremler wrote:
When usability and security conflict, security loses. Period.
Which is exactly opposite of good sense. :(
No, it's not.
I'm tired of this platitude from security people. It's just wrong.
Good security == maximally usable for the task at hand and minimally
usable for anything else.
The fact that an end user can't tell the difference is a fault from the
*security* side. Most of the applications are trying desperately to be
usable and play by the security rules. The fact that the applications
programmers cannot query the local security environment to make things
better for the user is what creates the security/usability tradeoff.
The "owner" only appears when he gets in the way of the "user". There
is no "owner" to please; there is only the "user". And the "user" has
said "Own my NAT, please!"
The obvious approach, I think, would be to build a NAT-control library,
like termcap and terminals. "Tell me what sort of NAT device you have,
and where it's at." A beneficial side-effect would be to allow for the
development of a set of open-source NAT-management tools built on top
of such a library.
Yes! That would be *fine*. However, no one from the land of security
has stepped forward to do the work required. Presumably it would be an
extension to SNMP.
Until then, we are stuck with subverting NATs.
There are plenty of ways for an active owner to stop traversal. Even
with hole punching, there are still plenty of ways to stop this (RST any
incoming connection without a rule stops all TCP hole punching cold).
By "active owner", I take it that you mean someone who explicitly allows
incoming connections through a firewall?
No, I mean owner with clue. One who doesn't say "Own my NAT, please!"
One who explicitly chooses the policy on the NAT rather than pulling it
out of the box, plugging in the cables, and never touching it again.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
