RE: IPSEC -vs- SSLJun 24 2004 03:31AM Brett OHara bmw com au (1 replies)
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):
> 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.
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.
[ reply ]