Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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)

share|improve this question
add comment

2 Answers

up vote 7 down vote accepted

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 that 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.

share|improve this answer
    
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
add comment

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.

share|improve this answer
    
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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.