Re: [fw-wiz] VPN endpoints

From: Kevin Sheldrake (kev_at_electriccat.co.uk)
Date: 08/31/04

  • Next message: Mason: "[fw-wiz] ISP firewalling of residential customers - was - About Port Forwarding, Apache and Firewall Rules"
    To: "Devdas Bhagat" <devdas@dvb.homelinux.org>, firewall-wizards@honor.icsalabs.com
    Date: Tue, 31 Aug 2004 21:48:15 +0100
    
    

    > On 30/08/04 14:48 +0100, Kevin Sheldrake wrote:
    >> 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.

    Ignoring momentarily the difficulty of quantifying risks, please bear in
    mind the post to which I was replying to had stated that VPNs were
    secure. My point was that that was an illogical statement as the term
    'secure' was situation dependent; what's secure when exposed to one
    environment is not necessarily secure when exposed to a different one. To
    that end it is certainly not well defined...

    Also, I tend to disagree with the notion that anything should be
    considered 'secure' - I prefer to take a risk management approach
    instead. Risk is inherent in information of any value, simply by virtue
    of a potential attacker existing. The threat agents do not necessarily
    disappear just because countermeasures have been implemented. When new
    vulnerabilities emerge, it isn't a case of are we still secure, but more
    like how much additional risk are we exposed to and what will possible
    countermeasures do to the risk? I suppose you could say "a system is
    secure when..." provides a binary value, where as risk management offers a
    full and rich array of useful information about the state of security.

    [ The less scrupulous of us might consider that a risk management approach
    always ends with the customer carrying some risk (as some risk is always
    inevitable); a desire over time to further reduce this risk may lead to
    more work! ;) ]

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

    It's not necessarily the OS that I'm worried about, more the untrusted
    network and management function that the client exists within. If your
    remote user can use any PC with a modern browser to SSL VPN into your
    network, then they can use PCs in Internet cafes, wireless access points,
    airport kiosks, etc. All you need is a crook managing the network and you
    could be looking at anything from keyboard sniffers through to hacked
    Internet browsers. SSL VPNs by their nature must trust the browser
    software and often the Java VM.

    A traditional IPSec VPN, however, requires a client and some reasonable
    key management. This will reduce the chances of an employee using a third
    party provided workstation to connect into the network. IPSec isn't as
    vulnerable to man-in-the-middle attacks, either.

    > 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.

    Okay, ettercapNG (ettercap.sourceforge.net) is a tool for
    man-in-the-middle attacks. It can perform an active attack on SSL in
    switched and hubbed networks. As part of the attack it switches the
    certificate with its own, signed by itself. This allows it to set up a
    tunnel to the client and another to the server; the data is decrypted at
    the ettercap attack workstation. All the user often sees different to the
    norm is a warning that something is a little odd with the certificate. In
    one browser it presented two green ticks to say the cert was in date and
    related to the right site, and one amber wiggly line to say it was signed
    by someone we _don't yet trust_. The user has two choices, 1) click No
    and don't get their email, have to ring the IT dept, this might be the
    next day if outside office hours, they may take a while to sort it, they
    may think the user is stupid... or 2) click Yes and get their email. It
    appears that many users will hit Yes.

    So, yes, it is the user at fault but the technology didn't really help
    itself, did it? It should have said "You don't trust this certificate.
    It could be fake. This could be an attempt at phishing. This could be a
    part of a hack. Report this to your IT dept." or perhaps something
    similar.

    Also, as I mentioned above, IPSec doesn't suffer this particular flaw. So
    if the technologies present different vulnerabilities, should they not be
    compared?

    > Actually a good idea if you are in a place where jobs are being
    > outsourced, plumbers are appaently rarer than unemployed IT personnel
    > and earn about the same.
    > PS: For the humour impaired, that last is a joke.

    I do believe in London plumbers earn more per hour than generalist IT
    contractors.

    Kev

    -- 
    Kevin Sheldrake MEng MIEE CEng CISSP
    Electric Cat (Bournemouth) Ltd
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
    

  • Next message: Mason: "[fw-wiz] ISP firewalling of residential customers - was - About Port Forwarding, Apache and Firewall Rules"

    Relevant Pages

    • More food for thought
      ... Basic Risk Analysis ... I have taken a position that the professional security community in general ... has and will continue to fail because they are operating under the same ... storing those backups safely offsite in a secure location on a daily basis. ...
      (comp.security.misc)
    • More food for thought
      ... Basic Risk Analysis ... I have taken a position that the professional security community in general ... has and will continue to fail because they are operating under the same ... storing those backups safely offsite in a secure location on a daily basis. ...
      (comp.os.ms-windows.nt.admin.security)
    • Re: [Full-disclosure] Risk measurements
      ... The cost of having all software formally verified far exceeds the losses. ... the cost of making Microsoft Office perfectly secure using ... An effective risk model can also make systems more secure. ... By allowing accurate risk calculations over a large population, insurance ...
      (Full-Disclosure)
    • Re: File encryption software?
      ... a passPRHASE is a very secure but easy to remember technique. ... Many applications still have an anachronistic limit on password length but PW Safe ... the downside risk is great. ... lived for 50+ years without needing the gun that I carry. ...
      (rec.outdoors.rv-travel)
    • Re: Wireless adapter security question
      ... "secure" network. ... That additional wireless connection is a clear risk to ... the local network. ...
      (alt.computer.security)