Re: [fw-wiz] VPN endpoints

From: Devdas Bhagat (devdas_at_dvb.homelinux.org)
Date: 08/30/04

  • Next message: Devdas Bhagat: "Re: [fw-wiz] VPN endpoints" 
    To: firewall-wizards@honor.icsalabs.com
Date: Tue, 31 Aug 2004 01:11:42 +0530

    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

  • Next message: Devdas Bhagat: "Re: [fw-wiz] VPN endpoints"

    Relevant Pages

    • Re: Goodbye to copper? [Telecom]
      ... and the definition of "curse" vs. ... The farmer feels they're a blessing. ... impacts of any new technology, and that responsibility belongs to both ... world' advocates blithely refuse any responsibility. ...
      (comp.dcom.telecom)
    • Re: Hi again everyone
      ... to lead to feeling as if you knew other participants pretty ... just by nature of how people had access (universities, ... of that - the technology has become universalized and people ... because things have changed so much "taking responsibility ...
      (rec.pets.dogs.behavior)
    • Re: Origins of Skylab MDA and Airlock Module
      ... >> The GT-4 problems we blame on technology not being tested for extreme ... The GT-9A problems we blame on technology being ... >True, but with the MDA on Skylab, I doubt this was an issue. ...
      (sci.space.history)
    • Re: Messenger is a pain in the ass!
      ... in the hands of teenagers are a pain in the ass, and a major waste of time". ... Blame it on something else. ... Using technology to communicate with other people is not a bad thing. ... I would be REALLY pissed off if someone prevented ME from using messenger! ...
      (microsoft.public.windowsxp.messenger)
    • Re: Diet, exercise, and Global Warming
      ... I agree with you about the need to take personal responsibility for our ... or that technology will be the cure..... ... earth through the ages of geologic time has warmed and cooled many times, ... that we humans aren't doing a bloody thing to help slow it down. ...
      (alt.support.diabetes)
    Loading