-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Let's digress.... "Neither SSH nor VPN"? I wasn't aware that there
> was a "VPN" protocol. If there is, please correct me and sent an
> RFC reference and I will be more than happy to look at it as well
> as admit my
> ignorance. If not, and you mean Virtual Private Network in a
> generic sense, then you would need to be more specific
I think his point is, that riding unsecured data streams inside a
secured transport, be it a secured stream or a secured virtual
network, doesn't address the issues that exist with the initial
unsecured stream. SSH or a VPN of any sort are examples of this.
> IPSec has the ability to
> create an end-to-end encrypted tunnel using session keys, *AND*
> encrypt the individual packets that are sent through that tunnel. I
> will grant you that many people utilize "tunnel-mode" which does
> exactly what you say, tunneling insecure protocols through a secure
> tunnel. However, when you tunnel an insecure protocol inside of a
> constant stream of garbage data that is encrypted using 2048 (or
> 4096)-bit keys, you would have to first penetrate the stream. By
> the time you do that, the session key has changed, and you have to
> start over again. I would say that IPSEC is the most secure (and
> probably the most complex) protocol out there, and there are
> several sub-protocols that make it up (ESP, AH, SHA, etc.). Now, if
> you are talking about PPTP, or an SSH-based VPN, then I would
> agree.
Yep, but now your talking at an environment level, and not an
application level. An application cannot mandate it run under a
secured environment.. :-)
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOp6E7093h3x1fgJJEQKKVgCgik6Xpgreo8e+lI+q6D02mauVXnwAoJdR
zGQ9L6ijzROaOJJ/0PhyAVXU
=HqHT
-----END PGP SIGNATURE-----
