[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fw: IPSec vs. SSL
I was not talking about the key setup phase for SSL, nor the key exchange
on IPSec, but more the products that we have trialed, where configuration
has to be done manually before IPSec will work. Whereas SSL is cert based
on the server with Key Setup from the client being trusted by third party.
I agree SSL is less secure and needs to be done from individual servers as
well, so the encryption has to be done at multiple points and servers, but
is also much simpler to deploy.
Ever tried running IPSec on demand in an Internet Cafe PC, getting access
to certain Internal pages securely. (SSL still has uses)
I agree with the last point, however SSL will still have uses within the
public arena such as for Web page security.
From: "Steven M. Bellovin" <firstname.lastname@example.org>@research.att.com on
18/12/2000 21:48 EST
Sent by: email@example.com
To: "Paul Heber" <firstname.lastname@example.org>
cc: Henry Spencer <email@example.com>, firstname.lastname@example.org
Subject: Re: Fw: IPSec vs. SSL
In message <OFFCB36D51.7DEBE250-ON4A2569BA.000EAB81@qantas.com.au>, "Paul
>> SSL is dynamic wheras IPSec needs setup and maintenance.
>Depends upon the implementation of the software, as to this setup and
I'm sorry, I still don't understand. SSL has a key setup phase, too.
To me, the difference is ease of deployment versus scope of protection.
SSL is easier to deploy, because it lives solely at user level. It
does not need any kernel mods, source code, etc., and is reasonably
portable between operating systems.
On the other hand, with SSL you have to secure one application at a
time. You can't protect entire subnets. There are trivial
denial of service attacks by active attackers; they simply need to
inject a single TCP packet. And there's no way to protect UDP.
If IPsec had been widely available, there would have been no need for
SSL. But it wasn't there; that left a gaping ecological niche that SSL
filled quite nicely.