Man, I hate to sound like a broken record, but this is not the case
with all SSL VPNs. In fact, it has never been the case with our
product specifically because of the problems that are created when one
tries to do this as a local proxy.
The NetScaler solution is 100% transparent to the applications, and
this is by design. Yes, the first SSL VPN products on the market
simply forced all traffic to be routed through the local proxy, and
this is how they were able to come to market so fast (62 new vendors
in one year alone). This created a huge number of issues, not the
least of which was you had to deal with things like embed links in
email, and the only way to do that was to write specific middle-ware
for every application that might have that kind of data. We chose
application transparency as a core design goal, so the proxy method
was obviously not going to work.
But enough about our product. My point is not to sell it here. My
point is that the realm of SSL usage is expanding far beyond previous
notions of its limitations, and when I see misstatements like this, or
broad characterizations that are not true, I have to say something.
Please forgive me if this came across as salesy.
-Shawn
On Thu, 24 Jun 2004 13:31:26 +1000, brett.ohara (at) bmw.com (dot) au [email concealed]
<brett.ohara (at) bmw.com (dot) au [email concealed]> wrote:
>
>
> One key item I'd like to add to the fray is that IPSec is transparent to the
> client. Every SSL implemetation effectively runs a local proxy for your
> application to connect to, hence to put data over the SSL tunnel, one needs
> to point ones application at 127.0.0.1:port, which then gets sent encrypted
> to the far end, some applications do not support this, hence it's not an
> appropriate method for those applications.
>
> You cannot seamlessly replace office LAN style connectivity (As IPSec is
> generally deployed) with SSL.
>
> You can however make specific internal applications available to a wider
> audience via an encrypted, authenticated portal.
>
> Seems like two different technologies with two different applications to me.
> Comparing the two just starts a typical Internet relgious argument.
>
> Regards,
> Brett
>
>
>
> -----Original Message-----
> From: Shawn Nunley [mailto:nunley (at) gmail (dot) com [email concealed]]
> Sent: Thursday, 24 June 2004 1:28 AM
> To: Stong, Ian C. (Contractor)
> Cc: firewalls (at) securityfocus (dot) com [email concealed]
> Subject: Re: IPSEC -vs- SSL
>
> Ian,
>
> I will answer your questions in-line below.
>
> On Wed, 23 Jun 2004 10:44:34 -0400, Stong, Ian C. (Contractor)
> <stongi (at) ncr.disa (dot) mil [email concealed]> wrote:
> >
> > Hi Shawn,
> >
> > Appreciate your comments - begs a few questions in my mind and would
> > appreciate any thoughts.
> >
> > My understanding of the two and comments/issues of each (please
> > correct where I am wrong) -
> >
> > SSL Based:
> >
> > 128 bit encryption
> > encryption only at the application layer (Note: there are some
> > alternatives here - see below)
>
> SSL and TLS support a plethora of cipher suites. The ICSA certification for
> SSL/TLS products states that products must support (at a minimum) at least
> one of the following cipher suites (from
> RFC3268):
>
> TLS_RSA_WITH_RC4_MD5 0x0004
> TLS_RSA_WITH_RC4_SHA 0x0005
> TLS_RSA_WITH_IDEA_CBC_SHA 0x0007
> TLS_RSA_WITH_3DES_EDE_CBC_SHA 0x000A TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA 0x000D
> TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA 0x0010 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
> 0x0013 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 0x0016 TLS_RSA_WITH_AES_128_CBC_SHA
> 0x002F TLS_DH_DSS_WITH_AES_128_CBC_SHA 0x0030
> TLS_DH_RSA_WITH_AES_128_CBC_SHA 0x0031 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
> 0x0032 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0x0033 TLS_RSA_WITH_AES_256_CBC_SHA
> 0x0035 TLS_DH_DSS_WITH_AES_256_CBC_SHA 0x0036
> TLS_DH_RSA_WITH_AES_256_CBC_SHA 0x0037 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
> 0x0038 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 0x0039
>
> > encryption from client to server or from client to SSL VPN
> > concentrator
>
> This varies by implementation, but the most common would be client-VPN
> concentrator. The tradition basic SSL session from client to server is not
> what we are talking about here at all.
>
> > "Clientless" approach - browser based so easy to deploy and support
>
> This was certainly the motivation for developing VPN products based on SSL
> and TLS! The idea that you can avoid the IT-touch factor associated with
> VPN deployment is very compelling.
>
> > Anyone with a browser can attempt a connection (issues: brute force
> > attack, DOS, ...)
>
> This is true of *any* service that exposes its front door to the web,
> without exception, including IPSec.
>
> > Potential for man in the middle attack, replay attacks and other SSL
> > vulnerabilities
>
> There are mechanisms built-in to the protocol to mitigate these threats.
> However, poor implementations on the client side (by the
> browser) have been encountered. The products that ship today have addressed
> all of the SSL/TLS issues that have been discovered and reported. If a
> company is concerned that their employees are going to be fooled by a MITM
> attack, they should account for that in their security policy and take steps
> to ensure that users have browsers without known problems. The use of
> mutual authentication (where the server is authenticated as well as the
> user) can mitigate this threat very well, and it gives IT great control over
> who can connect from what machine.
>
> > Protocol support improving. Covers most commonly used protocols TCP
> > and UDP supported. No other protocols supported - but may be able to
> > tunnel
>
> This is where most people just aren't getting it. Once the SSL tunnel is
> established, virtually ANY protocol can be tunneled quite transparently.
> Currently, our product supports any TCP, UDP, NETBios and some others.
>
> >
> > IPSEC Based:
> > Various encryption options up to 256bit AES
> > encryption at network layer
>
> Actually, all the same cipher suites are available to IPSec. The statement
> that it's at the Network layer (layer 3) is the most significant different
> between SSL/TLS and IPSec. Each has its advantages. IPSec is completely
> agnostic about the layers above layer 3, so it couldn't care less about UDP
> versus TCP. Conversely, with SSL/TLS at layer 7, it has much more context
> to work with. This contextual information is extremely useful when
> attempting to make AAA decisions about who can get to what. However,
> SSL/TLS is a stateful protocol and some of the protocols above layer 3 are
> not. There are good reasons that we have stateless protocols like UDP.
> Some conversations (especially encrypted conversations) cannot afford to
> lose even 1 bit, so if a packet is dropped is MUST be retransmitted.
> However, in the example of streaming video, it is better to ignore dropped
> packets because missing a frame of video is no big deal.
> Stopping to get that frame would cause choppy performance on the video
> stream. So, it is quite tricky to tunnel a stateless protocol over a
> stateful protocol and still maintain the quality of the experience that
> actually depends on the protocol ignoring dropped packets.
>
> All that being said, SSL/TLS products are quickly learning how to do this
> quite effectively. Ours supports UDP very well right now.
>
> > encryption from client to IPSEC concentrator (or other IPSEC
> > termination
> > device)
>
> Same as an SSL/TLS-based VPN.
>
> > Client based approach - need to install on remote system.
>
> Obviously, this can be a drag.
>
> >Potential issues
> > with home pc's in general as well as those with dual nic's, old
> >operating systems, application incompatibilities, etc.
>
> Actually, there are even more issues here. IPSec's Authenticated Header
> (AH) will usually break if you are behind NAT, and will certainly need holes
> opened in the firewall, so it is not often that you can connect from behind
> a NATing firewall. Add to that the fact that more and more hotels (finally)
> are putting in firewalls, and IPSec clients are facing a crap shoot every
> time they hit the road.
> To be fair, a lot of these products are finding ways to mitigate this
> problem, but the methods are unique to each vendor, and it means forgetting
> about the theoretical cross-vendor compatibility that was the initial
> promise of IPSec.
>
> > Connection attempt only from system with client installed. Must have
> > preshared key to get to auth phase
>
> This can be a real problem for remote clients who need to get in but have
> not yet been set up. Securely sharing keys has always been a problem.
>
> > Good security against man in the middle, replay attacks, etc. More
> > secure than SSL
>
> I would have to disagree with this one. I think both are equally 'secure'
> if implemented properly.
>
> > Full protocol support
> > TCP and UDP supported. Other protocol options if able to place in
> > IPSEC tunnel
>
> see above
>
> >
> > Mixture:
> > There are some products out that are a mixture of the two. I.E. they
> > use SSL to encrypt the connection and then also encrypt the data with
> > AES or similar encryption
>
> Again, SSL/TLS supports the same cipher suites, so this statement is just
> incorrect.
>
> >
> > Thanks,
> >
> > Ian Stong
> >
>
> Ian, thank you for the questions. I hope nobody on the list thinks I'm
> trying to sell here. I really just want people to be educated.
>
> >
> > -----Original Message-----
> > From: Shawn Nunley [mailto:nunley (at) gmail (dot) com [email concealed]]
> > Sent: Tuesday, June 22, 2004 1:56 AM
> > To: backup
> > Cc: Bastian Ballmann; firewalls (at) securityfocus (dot) com [email concealed]
> > Subject: Re: IPSEC -vs- SSL
> >
> > These kinds of proclamations would be better avoided when the facts
> > are in such a state of flux. While SSL VPNs *did* come to market with
> > support for limited protocols, the technology has advanced in huge
> > steps since that time. In fact, the SSL VPN product that my company
> > sells supports any IP-based protocol, with extremely few exceptions.
> > Even UDP can successfully be encapsulated within an SSL tunnel (it's
> > wasn't easy to do, but it's being done). All I'm saying is, the idea
> > that SSL VPNs are any less functional than IPSec is quickly becoming
> > outdated. There are differences in all implementation, even between
> > IPSec products (which was supposed to be easily implemented as a
> > multi-vendor solution, but did not quite turn out that way). We even
> > have a partnership with a secure video conferencing software company
> > just to show how easy it can be done with protocols that people assume
> > don't work.
> >
> > IMO, the only reason *some* vendors (not all) are offering both is to
> > provide a migration path for those large installed bases of IPsec.
> > Cisco, in particular, had lost so much IPsec business to SSL VPNs that
> > they were forced to 'adopt' the technology and claim their own SSL VPN
> > offering.
> >
> > Like I've said before, both technologies have solid security
> > fundementals *when implemented correctly*. It's not so much about
> > what applications work anymore, it's about how well they work and how
> > well you can control what is happening. SSL, being at layer 7, is
> > already armed with much more information in order to make more
> > fine-grained control possible. It would be difficult for an IPSec
> > product to have an access rule specifically for GETs and a different
> > access rule for POSTs on the same IP connection. On the other hand,
> > IPSec is currently much better suited for site-to-site becasue in this
> > aggregated traffic you rarely want to try and enforce layer 7 rules.
> >
> > -Shawn
> >
> > On Mon, 21 Jun 2004 11:19:58 +0530, backup <backup (at) roc.co (dot) in [email concealed]> wrote:
> > >
> > > SSL can only secure few applications like HTTP, SMTP etc., whereas
> > > IPSec can secure any type of applications that uses IP.
> > >
> > > One must understand that SSL is good for mobile users who wish to
> > > connect to their office network with easiness since it does not
> > > require any additonal client softwares for commonly used
> > > applications like HTTP, SMTP. As all of us know almost all browsers
> > > and SMTP clients have SSL support. Wherein case of IPSec client ,
> > > its more useful between corporate LANs.
> > >
> > > IPSec got its own advantage as it can work with any applications.
> > > voice and video applications can only work with IPSec.
> > >
> > > Thats is the reason every vendor now wishes to give its customers
> > > both IPSec and SSL based VPNs.
> > >
> > > Cheers,
> > > -Ravi
> > > ROCSYS Technologies Ltd.,
> > > http://www.rocsys.com
> > >
> > >
> > >
> > >
> > > Bastian Ballmann wrote:
> > >
> > > >Hi, there!
> > > >
> > > >On Thu, 2004-06-17 at 16:49, Stong, Ian C. (Contractor) wrote:
> > > >
> > > >
> > > >
> > > >>differences between an SSL based versus an IPSEC based VPN
> > > >>solution.
> > > >>
> > > >>
> > > >
> > > >SSL can only secure the application layer level of your
> > > >communication, but IPsec can also secure lower levels up to layer
> > > >3. That's why I prefer IPsec. HTH & Greets
> > > >
> > > >Basti
> > > >
> > > >
> > >
> > >
> >
> > --
> > Shawn Nunley, CISSP
> > Director, Technology Development
> > NetScaler, Inc.
> >
> >
>
> --
> Shawn Nunley, CISSP
> Director, Technology Development
> NetScaler, Inc.
>
--
Shawn Nunley, CISSP
Director, Technology Development
NetScaler, Inc.
with all SSL VPNs. In fact, it has never been the case with our
product specifically because of the problems that are created when one
tries to do this as a local proxy.
The NetScaler solution is 100% transparent to the applications, and
this is by design. Yes, the first SSL VPN products on the market
simply forced all traffic to be routed through the local proxy, and
this is how they were able to come to market so fast (62 new vendors
in one year alone). This created a huge number of issues, not the
least of which was you had to deal with things like embed links in
email, and the only way to do that was to write specific middle-ware
for every application that might have that kind of data. We chose
application transparency as a core design goal, so the proxy method
was obviously not going to work.
But enough about our product. My point is not to sell it here. My
point is that the realm of SSL usage is expanding far beyond previous
notions of its limitations, and when I see misstatements like this, or
broad characterizations that are not true, I have to say something.
Please forgive me if this came across as salesy.
-Shawn
On Thu, 24 Jun 2004 13:31:26 +1000, brett.ohara (at) bmw.com (dot) au [email concealed]
<brett.ohara (at) bmw.com (dot) au [email concealed]> wrote:
>
>
> One key item I'd like to add to the fray is that IPSec is transparent to the
> client. Every SSL implemetation effectively runs a local proxy for your
> application to connect to, hence to put data over the SSL tunnel, one needs
> to point ones application at 127.0.0.1:port, which then gets sent encrypted
> to the far end, some applications do not support this, hence it's not an
> appropriate method for those applications.
>
> You cannot seamlessly replace office LAN style connectivity (As IPSec is
> generally deployed) with SSL.
>
> You can however make specific internal applications available to a wider
> audience via an encrypted, authenticated portal.
>
> Seems like two different technologies with two different applications to me.
> Comparing the two just starts a typical Internet relgious argument.
>
> Regards,
> Brett
>
>
>
> -----Original Message-----
> From: Shawn Nunley [mailto:nunley (at) gmail (dot) com [email concealed]]
> Sent: Thursday, 24 June 2004 1:28 AM
> To: Stong, Ian C. (Contractor)
> Cc: firewalls (at) securityfocus (dot) com [email concealed]
> Subject: Re: IPSEC -vs- SSL
>
> Ian,
>
> I will answer your questions in-line below.
>
> On Wed, 23 Jun 2004 10:44:34 -0400, Stong, Ian C. (Contractor)
> <stongi (at) ncr.disa (dot) mil [email concealed]> wrote:
> >
> > Hi Shawn,
> >
> > Appreciate your comments - begs a few questions in my mind and would
> > appreciate any thoughts.
> >
> > My understanding of the two and comments/issues of each (please
> > correct where I am wrong) -
> >
> > SSL Based:
> >
> > 128 bit encryption
> > encryption only at the application layer (Note: there are some
> > alternatives here - see below)
>
> SSL and TLS support a plethora of cipher suites. The ICSA certification for
> SSL/TLS products states that products must support (at a minimum) at least
> one of the following cipher suites (from
> RFC3268):
>
> TLS_RSA_WITH_RC4_MD5 0x0004
> TLS_RSA_WITH_RC4_SHA 0x0005
> TLS_RSA_WITH_IDEA_CBC_SHA 0x0007
> TLS_RSA_WITH_3DES_EDE_CBC_SHA 0x000A TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA 0x000D
> TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA 0x0010 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
> 0x0013 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 0x0016 TLS_RSA_WITH_AES_128_CBC_SHA
> 0x002F TLS_DH_DSS_WITH_AES_128_CBC_SHA 0x0030
> TLS_DH_RSA_WITH_AES_128_CBC_SHA 0x0031 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
> 0x0032 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0x0033 TLS_RSA_WITH_AES_256_CBC_SHA
> 0x0035 TLS_DH_DSS_WITH_AES_256_CBC_SHA 0x0036
> TLS_DH_RSA_WITH_AES_256_CBC_SHA 0x0037 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
> 0x0038 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 0x0039
>
> > encryption from client to server or from client to SSL VPN
> > concentrator
>
> This varies by implementation, but the most common would be client-VPN
> concentrator. The tradition basic SSL session from client to server is not
> what we are talking about here at all.
>
> > "Clientless" approach - browser based so easy to deploy and support
>
> This was certainly the motivation for developing VPN products based on SSL
> and TLS! The idea that you can avoid the IT-touch factor associated with
> VPN deployment is very compelling.
>
> > Anyone with a browser can attempt a connection (issues: brute force
> > attack, DOS, ...)
>
> This is true of *any* service that exposes its front door to the web,
> without exception, including IPSec.
>
> > Potential for man in the middle attack, replay attacks and other SSL
> > vulnerabilities
>
> There are mechanisms built-in to the protocol to mitigate these threats.
> However, poor implementations on the client side (by the
> browser) have been encountered. The products that ship today have addressed
> all of the SSL/TLS issues that have been discovered and reported. If a
> company is concerned that their employees are going to be fooled by a MITM
> attack, they should account for that in their security policy and take steps
> to ensure that users have browsers without known problems. The use of
> mutual authentication (where the server is authenticated as well as the
> user) can mitigate this threat very well, and it gives IT great control over
> who can connect from what machine.
>
> > Protocol support improving. Covers most commonly used protocols TCP
> > and UDP supported. No other protocols supported - but may be able to
> > tunnel
>
> This is where most people just aren't getting it. Once the SSL tunnel is
> established, virtually ANY protocol can be tunneled quite transparently.
> Currently, our product supports any TCP, UDP, NETBios and some others.
>
> >
> > IPSEC Based:
> > Various encryption options up to 256bit AES
> > encryption at network layer
>
> Actually, all the same cipher suites are available to IPSec. The statement
> that it's at the Network layer (layer 3) is the most significant different
> between SSL/TLS and IPSec. Each has its advantages. IPSec is completely
> agnostic about the layers above layer 3, so it couldn't care less about UDP
> versus TCP. Conversely, with SSL/TLS at layer 7, it has much more context
> to work with. This contextual information is extremely useful when
> attempting to make AAA decisions about who can get to what. However,
> SSL/TLS is a stateful protocol and some of the protocols above layer 3 are
> not. There are good reasons that we have stateless protocols like UDP.
> Some conversations (especially encrypted conversations) cannot afford to
> lose even 1 bit, so if a packet is dropped is MUST be retransmitted.
> However, in the example of streaming video, it is better to ignore dropped
> packets because missing a frame of video is no big deal.
> Stopping to get that frame would cause choppy performance on the video
> stream. So, it is quite tricky to tunnel a stateless protocol over a
> stateful protocol and still maintain the quality of the experience that
> actually depends on the protocol ignoring dropped packets.
>
> All that being said, SSL/TLS products are quickly learning how to do this
> quite effectively. Ours supports UDP very well right now.
>
> > encryption from client to IPSEC concentrator (or other IPSEC
> > termination
> > device)
>
> Same as an SSL/TLS-based VPN.
>
> > Client based approach - need to install on remote system.
>
> Obviously, this can be a drag.
>
> >Potential issues
> > with home pc's in general as well as those with dual nic's, old
> >operating systems, application incompatibilities, etc.
>
> Actually, there are even more issues here. IPSec's Authenticated Header
> (AH) will usually break if you are behind NAT, and will certainly need holes
> opened in the firewall, so it is not often that you can connect from behind
> a NATing firewall. Add to that the fact that more and more hotels (finally)
> are putting in firewalls, and IPSec clients are facing a crap shoot every
> time they hit the road.
> To be fair, a lot of these products are finding ways to mitigate this
> problem, but the methods are unique to each vendor, and it means forgetting
> about the theoretical cross-vendor compatibility that was the initial
> promise of IPSec.
>
> > Connection attempt only from system with client installed. Must have
> > preshared key to get to auth phase
>
> This can be a real problem for remote clients who need to get in but have
> not yet been set up. Securely sharing keys has always been a problem.
>
> > Good security against man in the middle, replay attacks, etc. More
> > secure than SSL
>
> I would have to disagree with this one. I think both are equally 'secure'
> if implemented properly.
>
> > Full protocol support
> > TCP and UDP supported. Other protocol options if able to place in
> > IPSEC tunnel
>
> see above
>
> >
> > Mixture:
> > There are some products out that are a mixture of the two. I.E. they
> > use SSL to encrypt the connection and then also encrypt the data with
> > AES or similar encryption
>
> Again, SSL/TLS supports the same cipher suites, so this statement is just
> incorrect.
>
> >
> > Thanks,
> >
> > Ian Stong
> >
>
> Ian, thank you for the questions. I hope nobody on the list thinks I'm
> trying to sell here. I really just want people to be educated.
>
> >
> > -----Original Message-----
> > From: Shawn Nunley [mailto:nunley (at) gmail (dot) com [email concealed]]
> > Sent: Tuesday, June 22, 2004 1:56 AM
> > To: backup
> > Cc: Bastian Ballmann; firewalls (at) securityfocus (dot) com [email concealed]
> > Subject: Re: IPSEC -vs- SSL
> >
> > These kinds of proclamations would be better avoided when the facts
> > are in such a state of flux. While SSL VPNs *did* come to market with
> > support for limited protocols, the technology has advanced in huge
> > steps since that time. In fact, the SSL VPN product that my company
> > sells supports any IP-based protocol, with extremely few exceptions.
> > Even UDP can successfully be encapsulated within an SSL tunnel (it's
> > wasn't easy to do, but it's being done). All I'm saying is, the idea
> > that SSL VPNs are any less functional than IPSec is quickly becoming
> > outdated. There are differences in all implementation, even between
> > IPSec products (which was supposed to be easily implemented as a
> > multi-vendor solution, but did not quite turn out that way). We even
> > have a partnership with a secure video conferencing software company
> > just to show how easy it can be done with protocols that people assume
> > don't work.
> >
> > IMO, the only reason *some* vendors (not all) are offering both is to
> > provide a migration path for those large installed bases of IPsec.
> > Cisco, in particular, had lost so much IPsec business to SSL VPNs that
> > they were forced to 'adopt' the technology and claim their own SSL VPN
> > offering.
> >
> > Like I've said before, both technologies have solid security
> > fundementals *when implemented correctly*. It's not so much about
> > what applications work anymore, it's about how well they work and how
> > well you can control what is happening. SSL, being at layer 7, is
> > already armed with much more information in order to make more
> > fine-grained control possible. It would be difficult for an IPSec
> > product to have an access rule specifically for GETs and a different
> > access rule for POSTs on the same IP connection. On the other hand,
> > IPSec is currently much better suited for site-to-site becasue in this
> > aggregated traffic you rarely want to try and enforce layer 7 rules.
> >
> > -Shawn
> >
> > On Mon, 21 Jun 2004 11:19:58 +0530, backup <backup (at) roc.co (dot) in [email concealed]> wrote:
> > >
> > > SSL can only secure few applications like HTTP, SMTP etc., whereas
> > > IPSec can secure any type of applications that uses IP.
> > >
> > > One must understand that SSL is good for mobile users who wish to
> > > connect to their office network with easiness since it does not
> > > require any additonal client softwares for commonly used
> > > applications like HTTP, SMTP. As all of us know almost all browsers
> > > and SMTP clients have SSL support. Wherein case of IPSec client ,
> > > its more useful between corporate LANs.
> > >
> > > IPSec got its own advantage as it can work with any applications.
> > > voice and video applications can only work with IPSec.
> > >
> > > Thats is the reason every vendor now wishes to give its customers
> > > both IPSec and SSL based VPNs.
> > >
> > > Cheers,
> > > -Ravi
> > > ROCSYS Technologies Ltd.,
> > > http://www.rocsys.com
> > >
> > >
> > >
> > >
> > > Bastian Ballmann wrote:
> > >
> > > >Hi, there!
> > > >
> > > >On Thu, 2004-06-17 at 16:49, Stong, Ian C. (Contractor) wrote:
> > > >
> > > >
> > > >
> > > >>differences between an SSL based versus an IPSEC based VPN
> > > >>solution.
> > > >>
> > > >>
> > > >
> > > >SSL can only secure the application layer level of your
> > > >communication, but IPsec can also secure lower levels up to layer
> > > >3. That's why I prefer IPsec. HTH & Greets
> > > >
> > > >Basti
> > > >
> > > >
> > >
> > >
> >
> > --
> > Shawn Nunley, CISSP
> > Director, Technology Development
> > NetScaler, Inc.
> >
> >
>
> --
> Shawn Nunley, CISSP
> Director, Technology Development
> NetScaler, Inc.
>
--
Shawn Nunley, CISSP
Director, Technology Development
NetScaler, Inc.
[ reply ]