Re: VPN endpoints

["Kevin Sheldrake" <kev () electriccat co uk>]

> 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