Re: [fw-wiz] VPN endpoints

• Next in thread: Paul D. Robertson: "Re: [fw-wiz] VPN endpoints"
• Maybe reply: Paul D. Robertson: "Re: [fw-wiz] VPN endpoints"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

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 in thread: Paul D. Robertson: "Re: [fw-wiz] VPN endpoints"
• Maybe reply: Paul D. Robertson: "Re: [fw-wiz] VPN endpoints"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]