is it recommended to use both protocols together? In which situation?
4Sure. Say I am in a different country and don't want my internet traffic snooped on. I can use IPSec to tunnel the internet traffic back to a server in my home country. Once that traffic leaves that server in my home country it will no longer be encrypted. So I use SSL to connect to, for example, a web mail server.– mikeazoJul 17, 2014 at 11:44
2I don't understand if you mean that from first country to my home the flow is encrypted with IPsec, and from my home to the mail server it is encrypted with SSL, or you mean that I use IPsec and SSL simultaneously from first country?– mcfanJul 17, 2014 at 13:11
1Well technically from the first country to your home the connection would be encrypted with IPSec and SSL. When it reaches your home country, IPSec is removed and only SSL remains.– mikeazoJul 17, 2014 at 13:23
@OP, It may be easier for a firewall-with-keys to sniff SSL than IPSEC.– PacerierOct 24, 2017 at 7:05
There are different layers of secure transport to consider here:
- SSL VPN (including tunnels)
- IPSec VPN
- SSL/TLS for individual services
IPSec vs SSL VPNs
Both SSL and IPSec VPNs are good options, both with considerable security pedigree, although they may suit different applications.
IPsec VPNs operate at layer 3 (network), and in a typical deployment give full access to the local network (although access can be locked down via firewalls and some VPN servers support ACLs). This solution is therefore better suited to situations where you want remote clients to behave as if they were locally attached to the network, and is particularly good for site-to-site VPNs. IPSec VPNs also tend to require specific software supplied by the vendor, which is harder to maintain on end-user devices, and restricts usage of the VPN to managed devices.
SSL VPNs are often cited as being the preferred choice for remote access. They operate on layers 5 and 6, and in a typical deployment grant access to specific services based on the user's role, the most convenient of which are browser-based applications. It is usually easier to configure an SSL VPN with more granular control over access permissions, which can provide a more secure environment for remote access in some cases. Furthermore, SSL/TLS is inherently supported by modern devices, and can usually be deployed without the need for specialist client-side software, or with lightweight browser-based clients otherwise. These lightweight clients can often also run local checks to ensure that connecting machines meet certain requirements before they are granted access - a feature that would be much harder to achieve with IPSec.
In both cases one can be configured to achieve similar things as the other - SSL VPNs can be used to simply create a tunnel with full network access, and IPSec VPNs can be locked-down to specific services - however it is widely agreed that they are better suited to the above scenarios.
However, for exactly these reasons, many organisations will use a combination of both; often an IPSec VPN for site-to-site connections and SSL for remote access.
There are a number of references on the subject of SSL vs IPSec (some of these are directly from vendors):
In some of the above cases, such as IPSec VPNs and SSL VPN tunnels, you may not be getting end-to-end encryption with the actual service you're using. This is where using an additional layer of SSL/TLS comes in handy.
Say you're remote and trying to connect to an internally hosted web application via an IPSec VPN. If you use the HTTP protocol via your browser, your traffic is encrypted whilst it is running through the VPN tunnel itself, but it is then decrypted when it hits the remote VPN endpoint, and travels over the internal network in cleartext. This might be acceptable in some use cases, but in the interest of defence in depth, we ideally want to know that our data cannot be intercepted anywhere between you and the actual service itself. By connecting to this application over HTTPS, you effectively have two layers of security: one between you and the VPN endpoint, and another travelling through that (between you and the web server itself).
Of course, this is not limited to HTTPS - you should equally employ other secure protocols like SSH, FTPS, SMTP with STARTTLS etc etc.
1IPSec isn't just for VPNs though. You can use it between hosts Nov 10, 2017 at 21:33
Here's a good article from cisco on IPSEC and SSL. It includes strengths and weaknesses as well as an overview of each, and also implementing both of them together.
1I'm not sure this is what the OP is looking for. He asks about using IPSec and SSL at the same time. This article is about using an IPSec VPN vs SSL VPN.– mikeazoJul 17, 2014 at 15:11
1It talks about using both towards the end of the article.– BobJul 17, 2014 at 15:38
The end of the article talks about why you would want to setup both an SSL VPN and an IPSec VPN. It doesn't talk about when you would use both at the same time. I think (though I could be wrong) that the OP is looking for use cases where you would use both IPSec and SSL at the same time.– mikeazoJul 17, 2014 at 15:52
It depends you may have corporate VPN Tunnel (that works on IPSEC) but a layer above the internal web server you are reaching over VPN in the corporate network might be HTTPS( which is via SSL)
Long back i did a talk on this
There are reasons for using both protocols. When using an IPsec tunnel you would still want application level encryption. This is advantageous if there is a gap between the end of the tunnel and where your session ends.
The following diagram describes why you may want application level encryption like HTTPS (SQL in my example) in addition to IPsec.
User => Website => IPSec Tunnel => Back End Network => SQL Backend | => Data can be read by other hosts!
1So isn't IPSEC making things redundant and slow?– PacerierOct 24, 2017 at 6:54
It doesn't make sense to use both at the same time. Yes, IPsec tunnel "dissolves" at the edge routing firewall, but in the similar fashion TLS "dissolves" inside DMZ, usually HTTP server, i.e. if I am a hacker I would not bother with site-to-site network layer secured pipe nor TLS transport layer pipe from edge firewall to DMZ HTTP server.
Instead I would focus my efforts to attack HTTP-to-application server link. The only way to protect against that would be to extend the secure pipe all the way to the application, but neither TLS nor IPsec VPN can do that or is too cumbersome.
That leaves payload encryption and digital signing as the only choice, but in that case one needs only either TLS or IPSEC pipe, not both at the same time (for equivalent security and to meet performance targets). If payload (application) level security is not possible to implement, having both TLS and IPSEC pipe at the same time would not significantly increase the security, while at the same time it would significantly degrade the performance.
IPsec by itself does not secure end users (billions of them)—they do not have direct IP access outside the private network⟶they connect through ISPs.
(The upshot: If you're building a public-network end user application, you can't use IPsec.)
That is where TLS and others (eg SSH) comes in. They give end-user security in the face of ⨕ the growing list of entitled and ⨕ incompetent ISPs/governments.