2

In my software both the server and the client sends unencrypted TCP keepalive messages to be able to detect the broken pipe within a reasonable time. It also uses TLS 1.3 encryption with OpenSSL 1.1.1.

Are there any security concerns about this?

For example: Man-in-the-middle attacker disrupt the communication. To spoof both sides that the connection is still alive, he regularly sends/forwards TCP keepalives.

Is this scenario possible? Is it likely?

What other scenario can you think of?

Improve this question
5
  • 2
    But if you already have established a TLS connection, why do you not use the Heartbeat extension? It was made for exactly this purpose. It just got a bad reputation because it was implemented in a broken way in OpenSSL, but Heartbeat itself is fine.
    – user163495
    Commented Nov 16, 2019 at 18:44
  • Do you have a secure method of telling the pipe to close? Is there information leakage in the keep alive message session/client info?
    – Michael Hearn
    Commented Nov 16, 2019 at 18:45
  • 1
    @MechMK1 The heartbeat extension has been completely removed from OpenSSL due to the bad reputation it has received. ( Source ). Initially, I wanted to use that.
    – Sylvester
    Commented Nov 16, 2019 at 20:10
  • @Michael Hearn I don't really understand the question. I use simple TCP keepalive link in a C software on Linux link. I think this is as safe as an unencrypted protocol can be.
    – Sylvester
    Commented Nov 16, 2019 at 20:10
  • @Sylvester wow can’t believe they would do that. I was wondering if the unencrypted keep alive messages were custom that you built into your program. Or Standard keep alive messages.
    – Michael Hearn
    Commented Nov 16, 2019 at 20:20

1 Answer 1

Reset to default
2

... server and the client sends unencrypted TCP keepalive messages

A TCP keepalive message is a packet with no payload, i.e. the length of the application data is 0. The objective of TLS is to protect the application data against sniffing and modification. Since there are no application data in the TCP keep alive message in the first place there is nothing to protect here. In fact, TLS is not even aware of TCP keepalive and there is no need that it needs to be aware of it.

For example: Man-in-the-middle attacker disrupt the communication. To spoof both sides that the connection is still alive, he regularly sends/forwards TCP keepalives.

TLS does not care about the status of the TCP connection. It only cares about the transferred application data. TLS does not even see the TCP keepalive messages and has no way to trigger these.

The whole purpose of TCP keepalive is to keep an idle connection open and to detect connection loss within an idle connection. Connection loss or failure to detect it is usually not seen as a security problem since no actual application data are affected. If your specific applications requires such detection for security reasons and in a tamper-resistant way then you need to implement some kind of heartbeat at your application level or use the infamous TLS heartbeat extension if supported by your specific TLS stack.

Improve this answer
8
  • TLS provides more than the confidentiality of the application data. It also provides integrity, and authentication. You are right, that there is nothing to protect here, since there is no payload, but in my opinion an attacker can still tamper with these messages, since their integrity cannot be checked and the sender cannot be authenticated. What do you think about this?
    – Sylvester
    Commented Nov 17, 2019 at 9:03
  • @Sylvester: I did not claim that it only provides confidentially. I've said that it protects against sniffing and modification. Protecting against modification is integrity. Protecting against sniffing requires authentication since otherwise some attacker could just MITM the connection. But the objective of TLS is the protection and authentication is just one part necessary to achieve the protection.
    – Steffen Ullrich
    Commented Nov 17, 2019 at 9:07
  • @Sylvester: "... but in my opinion an attacker can still tamper with these messages, ..."* - again, TLS cares only about protecting the application data. TCP keep alive does not include any application data so there is nothing to protect here. TLS does not care about the underlying TCP connection at all, in fact it can be used on top of other transport protocols (like SCTP) too. While one might wish that TLS does more than protecting the application data this was never its objective. It is not a design flaw in the protocol but instead wrong assumptions on what the protocol provides.
    – Steffen Ullrich
    Commented Nov 17, 2019 at 9:11
  • I agree with every word you say, but I do think that there is still some security concern here. Is it possible for a man-in-the-middle attacker to make some packets "disappear", or cut the connection between the peers? If so, then I think the scenario I presented is possible. I don't think this is a valid thing to be afraid of between webservers and browsers, but in case of critical infrastructures it could do a lot of damage. In my case, I do need this kind of tamper-resistant detection. I already implemented this, but I'm afraid it's not tamper-resistant due to keepalive.
    – Sylvester
    Commented Nov 17, 2019 at 9:51
  • @Sylvester: it is impossible for the attacker to make some packets in the middle disappear as long as these packets contain application payload. TLS already protects against this since TLS frames have an implicit sequence number which is part of the integrity check. But of course an attacker can simply cut the connection and there is nothing TLS or TCP or IP can do against this - but this does not affect the protection of the application data. Again, TLS has a clear objective but you expect something from it which is not in this objective.
    – Steffen Ullrich
    Commented Nov 17, 2019 at 10:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .