Re: VPN endpoints

[Devdas Bhagat <devdas () dvb homelinux org>]

On 30/08/04 14:12 -0400, Paul D. Robertson wrote:
> On Mon, 30 Aug 2004, Devdas Bhagat wrote:
>
> > > VPNs are not secure by default for two differently abstracted reasons:
> > > 1) Some VPN products default to allowing the Null encryption algorithm.
> >
> > That is seriously broken. Have a list you can share?
>
> Note that "default to allowing" is different than "default to using."  One
> of my few gripes with ICSA Labs SSL VPN criteria was in even allowing a
> null cipher to be specified.
However, in a large number of cases, the defaults get used. This is
broken. But that just means that the defaults need to be changed.
After all, isn't one of the main gripes with Microsoft that they put
extremely bad defaults on their OS?

> > > So, unless you like no encryption, VPNs are not secure (although some
> > > specific examples may be 'secure' (see 2)).   Also, bear in mind the
> > > implementation of the VPN encryption algorithms might not be textbook -
> > > how will you know?
> > >
> > > 2) 'Secure' is an undefined term.  What's secure for me might not be
> >
> > "Secure" is a very well defined term.
> >
> > A system is secure when the cost of an unauthorised entity accessing the
> > data on the system or the loss of the data itself is higher than the value
> > of the data itself.
> >
> > However, this definition of security involves terms like cost, the
> > calculation of which which is not very well understood by the general
> > population.
>
> Nor the general security practicioner ;)

Hopefully, the general practitioner knows this and can pass
responsibility on to someone with better data with which to make
judgement calls (aka the finance department).

The security practitioner can say:
"You have possible holes at point a, b and c. The risk of one of
these points getting hit is x, y and z respectively. An intrusion would
lead to compromise of data on networks l, m and n respectively."

The first and third statements are easy to judge, the risk analysis is
not so easy without access to a lot of data.

<snip>
> > The problem as I see it is not the technology itself, it is the fact
> > that the technology puts a great deal of responsibility for policy
> > enforcement on the end user who is non technical that is the problem.
>
> Actually, I think the technology needs a little blame.  Traditional
> red/black network designs are great for crypto, as is potentially,
> LAN-to-LAN VPN- it's the "untrusted, general computing client with split
> tunneling or network roving" problem that's not well-solved by current
> technological solutions.  Smart cards might help some, as does turning off
> split tunneling, personal firewalls, etc.  But the technology isn't ideal
> for the solutions it's being sold for.

And the fault of the technology is? If you try to fit a square peg into
a round hole, and it doesn't fit, don't blame the peg.

You just restated my point in different words :)

Current technology puts a great deal of responsibility on the user to
keep his/her systems secure. In the case of the roving user, this is not
a valid assumption.

Blame the marketing folks who managed to sell this as a working solution
when it is not.

Devdas Bhagat
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards