Ronald and Francis, It is important to remember that the basis of analysing a VPN solution lies in the so-called CIA - confidentiality, integrity and authentication offered by the implementation. Encryption algorithms (DES, AES, Blowfish, etc), hashing algorithms (SHA, MD5, etc) and key-exchange methods (Diffie-Helman, etc) give us the CIA characteristics of each VPN solution. Also important is non-repudiation.
In general, IPSec and SSL VPNS do the same thing, securing data as it crosses the hostile topology. In fact, the two share basic approaches to implementing the security mechanisms of encryption and authenication. IPSec implementations are usually run in kernel-space and therefore involve the OS a great deal, and the kernel is actively involved in tampering with packets as they enter and exit. SSL VPNs will more often run as a normal application - in user space - and all they may need is a virtual adaptor (tun/tap) to write and read encrypted data from, and the kernel will send off these packets like any other packet. Where and when? IPSec - managed (or manageable) clients like 10 staff who want to work remotely. SSL - unmanaged (or unmanageable) clients like 10000 customers doing e-banking. I do know of two SSL VPN flavors that differ considerably. Web-based SSL VPNs, like the Cisco type, will need a client to connect via a web browser and then they push something like a Java applet to the client to take care of the encryption, squish the malware and eat up all the cookies afterwards, etc. Then there's the wonderful OpenVPN, which qualifies to be SSL VPN in the sense that it uses the Secure Sockets Layer and Transport Layer Security (TLS) framework, built into packages like OpenSSL to encrypt and securely exchange data over the network. Now, ease of implementation really depends on where you come from and where you want to go, and definately YMMV. Bernard > On 6/30/06, Francis Musinguzi <[EMAIL PROTECTED]> wrote: >> >> Kurup, >> >> "There are a number of VPN products freely available; some are >> kernel-level like openswan and can be fairly difficult to configure. >> OpenVPN, available at http://openvpn.net/, doesn't require patching the >> kernel and can be extremely straightforward. Configuration is more >> difficult >> if you want to use a lot of its features, but for a quick client/server >> VPN, >> you can be up and running in minutes." >> >> There in lies the problem. There are so many free voices allowed to >> publish their feelings, not accompanied by proven facts. There is no >> practical way to add all that functionality without sacrificing on >> secrutiy. >> IPSec is supposedly very secure, but is a menace to setup and support. >> > > Being a menace to setup and support can be a menace to crack :-) I think > IPSec wouldn't be a bad way to go especially when u count on security very > much. > > Most IPSec implementations are kernal-based requiring kernal knowledge. >> Ofcourse any errors can lead to total (security) system failure. This >> makes >> the user-space level VPN solutions more freindly to use. Kiggundu >> recently >> sent a link to a site where the " Are SSL based VPNs more secure than >> IPSec >> VPNs?" >> > > I think NO... the reverse is true. > > debate was briliantly tackled. Sorry I failed to find the link but you > could >> google it. >> >> I've not personally tested all different VPN solutions but most content >> acorss the NET seems to suggest that be wary. The ball is therefore in >> your >> court. >> >> However having implemented OpenVPN, I'm satisfied with the current level >> of "Security", ease of use and scalability. >> > > Thats right implementing others would be fun.. > > FRANCIS. >> >> ========================================================================== >> >> >> Hari Kurup writes: >> >> On Jun 29, 2006, at 4:13 AM, Francis Musinguzi wrote: >> >> PS: OpenVPN is a faster way to get the IP tunnels giong. (CISCO, >> OpenSWAN >> and IPSec die-hards take note) >> >> Alright, faster to setup. >> >> But are SSL based VPNs more secure (the whole idea of VPN) than IPSEC >> ones? Please enlighten me coz I think not. >> >> Kurup >> >> >> _______________________________________________ >> LUG mailing list >> [email protected] >> http://kym.net/mailman/listinfo/lug >> %LUG is generously hosted by INFOCOM http://www.infocom.co.ug/ >> >> The above comments and data are owned by whoever posted them (including >> attachments if any). The List's Host is not responsible for them in any >> way. >> --------------------------------------- >> >> >> >> > > > -- > Ronald Nsubuga > Network Engineer > one2net Limited > --------- > Everything can be achieved as long you can do what it takes to achieve it! > " > The More Things Change The More Things Stay The Same " > ---------------------------------------------- > _______________________________________________ > LUG mailing list > [email protected] > http://kym.net/mailman/listinfo/lug > %LUG is generously hosted by INFOCOM http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The List's Host is not responsible for them in any > way. > --------------------------------------- > > _______________________________________________ LUG mailing list [email protected] http://kym.net/mailman/listinfo/lug %LUG is generously hosted by INFOCOM http://www.infocom.co.ug/ The above comments and data are owned by whoever posted them (including attachments if any). The List's Host is not responsible for them in any way. ---------------------------------------
