18

Maybe you could help me with a small problem.

Would you recommend IPSec or TLS for a Server-to-Server-Connection? I need two or three arguments for reasoning a decision within my final paper, but sadly didn't find a criterion for an exclusion. The reflection of IPSec and TLS within my thesis is only a minor aspect, therefore, one or two main reasons for selecting TLS or IPSec would be enough. Do you think the possible compression within IPSec could be one of these main reasons?

More complete explanation of the scenario:

A user wants to login on a portal to make use of a service. The portal backend consists of the portal itself, a registration authority, user management, access control authority etc. Should I choose TLS or IPSec to secure those Backend connections? The delivered service does not have to be positionated within the backend, but it is reliable and is only connected with the portal. Here's a list with the connections I want to secure:

service (may be an external one) ---- portal

registration authority ---- user management

portal ---- user management

for a user-server-connection I've already made my decision, but the reasons I've used for this decision, doesn't work for a server-to-server-connection.

Thanks a lot in advance!

A picture of the scenario:

(red = problematic connection)

enter image description here

(in fact the model is by far larger, since I treat also other mechanisms like authentication, storage-mechanisms, storage access, access control, software-architecture, including possible technologies and so on. Therefore, securing the connections is only a partial aspect)

Saturas
  • 183
  • 1
  • 1
  • 5

2 Answers2

25

There are two main usage modes for IPsec: AH and ESP. AH is only for authentication, so I suppose that you are talking about an ESP tunnel between the two servers. All IP packets get encrypted and authenticated, including some header details such as the source and target ports. There are several encryption and MAC algorithms which can be used with IPsec; AES (CBC mode, 128-bit key) and HMAC/SHA-1 (truncated to 96 bits) are fine, and are MUST-implement, so any conforming IPsec implementation should support them.

For this "tunnelling" part, IPsec does things correctly, and so does TLS (assuming TLS 1.1 or 1.2, for IV selection with block ciphers in CBC mode). In fact IPsec can be deemed to be "more correct" than TLS because it uses encrypt-then-MAC instead of MAC-then-encrypt (see this); however, properly implemented TLS 1.1 or 1.2 will be fine too. Practical differences will occur at other levels:

  • To encrypt and decrypt data, your two servers must first agree on a shared secret. This is what the handshake in TLS is about; the equivalent in IPsec would be IKE. You might want to rely on X.509 certificates; or maybe on a "shared key" manually configured in both servers. Both TLS and IPsec support both, but any specific implementation of either may make one option easier or more complex than the other.

  • IPsec acts at the OS level; application software needs not be aware of the presence of IPsec. This is great in some cases, not so great in others. On the one hand, it allows some legacy applications to be "secured" with IPsec even if this was not envisioned during application development; and the security management can be done without being constrained by what the application developers thought of (for instance, if using X.509 certificates, you can enforce revocation checks, whereas a TLS-powered application might use a library which does not support CRL). On the other hand, with IPsec, applications cannot do anything application-specific with security: a server may not, for instance, vary its security management depending on which other server is talking to it.

  • Though TLS is normally used applicatively, it is also possible to use it as building block for an OS-level VPN between the two servers. This basically means using TLS as if it was IPsec.

  • IPsec being OS-level, its operation implies fiddling with OS-level network configuration, whereas TLS can usually be kept at application level. In big organizations, Network people and application people tend to live in separate worlds (and, sadly, are often at war with each other). Keeping everything at the application layer may make the deployment and management easier, for organizational reasons.

Summary: it depends. Use IPsec if you want to apply it on uncooperative applications (e.g. an application which does not natively support any kind of protection for its connections to other servers). Use TLS if you want to abstract away OS-level configuration. If you still want to use TLS and yet do so at OS level, then use a TLS-powered VPN.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • Wow, thanks for your comprehensive answer! I've forgotten to note that I should argue on a very abstract level independent from the OS or the implementation. I've edited my starting-post, to give you an idea how abstract the considerations are. I think that the communication between portal and service should be secured by IPSec, since the service could be an external one. If I get you right, the portal provider (PP) does not have to consider, how the service was exactly implemented, if IPSec is used. As a result the PP would be more flexible in which service he wants to integrate. Am I right? – Saturas Sep 26 '13 at 16:02
  • Since I have to work on model level, I'm not sure, if I am allowed to argue on an implementation level. So.. what do you think, should I use as reason for choosing TLS or IPSec for the communication between portal and user management (UM) and for the communication between registration authority and UM? If I understood right, IPSec would be more difficult to configure (I'm not sure if this counts in that case), woudln't it? Do you think the compression-function of IPSec could be one reason for IPSec? (I've should focus on IPSec and TLS as they are, whatever this means) – Saturas Sep 26 '13 at 16:09
  • At a high abstract level, the only difference between IPsec and TLS is that IPsec makes a secure tunnel between two _machines_ while TLS makes a tunnel between two _applications_ (but this is secure only if the machines' OS are not hostile). As for compression, it usually better addressed at application level, because applications "know their data" and can be more efficient at it. Also, compression tends to be in somewhat uneasy terms with encryption, because encryption leaks data _length_, and compression makes data length dependent on data _contents_. It has led to trouble in some cases. – Tom Leek Sep 26 '13 at 16:23
  • @TomLeek, Since TLS is layer 5 and IPsec is layer 3, for maximum securityu couldn't we combine them by running TLS on top of IPsec? – Pacerier Apr 06 '15 at 16:52
  • "Layers" are ill-defined. For instance, if you use a TLS-based VPN, then the TLS must be both above layer 4 and below layer 3, a logical impossibility. Trying to map all network activity into the rigid "layer" terminology is bound to be restrictive and spread confusion. As for combining two encryption systems to obtain "maximum security", it is called _cascading_ and is not really recommended (cascading surely increases _usage cost_, but it "increases" security only insofar as one of the cascaded protocols is broken, and it would be smarter not to use a broken protocol at all). – Tom Leek Apr 21 '15 at 14:01
  • @TomLeek, Re "it is also possible to use it as building block for an OS-level VPN between the two servers", isn't such tunneling true of **every** protocol? ¶ Also, could cascading actually be *less* secure? Is that even possible? – Pacerier Oct 24 '17 at 08:56
0

Which implementation of TLS did you have in mind? Stunnel? IPsec and Stunnel provide comparable security, but Stunnel is much easier to set up. IPsec has a steeper learning curve but provides more features, including the holy grail of labeled networking when used with SELinux on both sides.

Matrix
  • 3,988
  • 14
  • 25
  • Thanks for your response. The thing is that I have to argue on a more abstract level. The argumentation should be independent from a concrete implementation since it's only a minor aspect of my thesis. For the user-server-communication I've recommended to use TLS for the connection because it's natively supported by the users browser: No installation and configuration of software is required, what makes it more user-friendly. I hope to find one or two 'abstract' reasons like that for a server-to-server-connection (would the compression of IPSec be a first one?) – Saturas Sep 26 '13 at 13:13
  • And sorry if my questions sound a bit clumsy but I've only been involved in this since shortly – Saturas Sep 26 '13 at 13:13