Re: VPN endpoints

["Paul D. Robertson" <paul () compuwar net>]

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.

> > 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 ;)

> > secure for you - it all depends upon the sensitivity of the information
> > and the impact on the business in cases of compromise, whether that be
> > confidentiality, integrity or availability.
>
> The cost of compromise is a function of the risk that the data may be
> compromised. The hard part of doing any type of security work is in
> calculating this risk. I don't know of any insurance company that has
> formulae to estimate such risks.
>
> > SSL VPNs are IMHO generally a bad idea.  In a nutshell, this is because
> > most of the benefits are in the fact that practically any client can be
> > used, and that the authentication mechanisms are not particularly
> > intrusive (and often are fault-tolerant).  By allowing uncontrolled
> > clients you introduce potentially major risks; controlling the clients
>
> <not_a_troll>
> Is a Microsoft Windows (tm) system that has been connected to a non trusted
> network a controlled client?
> </not_a_troll>
>
> Replace MS Windows by any other OS of choice, as needed. The only reason
> I use that example is because it is the most common one around.
>
> > would point back towards a traditional IPSec solution.  The authentication
> > mechanisms may be compromised by a little technology and average user
> > ignorance (fake certificates, for instance); restricting the
> > authentication mechanisms would again point back towards traditional IPSec
> > solutions.
>
> 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.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul () compuwar net       which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards