46

I have an upcoming oral network security exam and know that in past exams, the professor asked about why TLS requires TCP. I know that there is DTLS but it wasn't part of the lecture. So the question is about what advantage TLS gains by requiring its underlying protocol to be TCP, I guess. I already heard some wild guesses but no convincing arguments.

In the beginning of the RFC, it says:

At the lowest level, layered on top of some reliable transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol.

Seemingly everywhere else (according to my judgment), the RFC doesn't only require "some reliable transport protocol" but TCP in particular.

Community
  • 1
UTF-8
  • 2,300
  • 1
  • 9
  • 24
  • 7
    The things DTLS does that TLS doesn't need (because of TCP) are detailed by The Great Bear in https://security.stackexchange.com/questions/29172/what-changed-between-tls-and-dtls . – dave_thompson_085 Oct 07 '17 at 23:02
  • 3
    'According to your judgment' why? 'Everywhere else' such as where? The actual premisses of your question are not even stated here. – user207421 Oct 09 '17 at 00:01
  • Wow this a new one. In a networking class we constructed a reliable protocol on top of UDP that had better packet recovery semantics than TCP. You could certainly stack TLS on it. I'm pretty sure you could also stack TLS directly over serial line, but why would you want to? – Joshua Oct 08 '17 at 22:41

4 Answers4

70

TLS requires a reliable transport. On the internet, this leaves only TCP, as UDP does not offer reliability.

TLS does require a reliable transport because (in compliance with the layered architecture of the ISO/OSI reference model) it does not handle transport errors, lost packets or other disturbances that may occur with IP.

TLS is designed to offer a secure channel on top of a reliable transport and it does this quite well. DTLS does (I assume) the necessary error handling within the protocol.

If TLS was to be performed over UDP, connections and handshakes could fail just because a packet got lost in transit and no one noticed.

Mitigation of such problems is (according to the ISO/OSI reference model) the designated task of a reliable transport. Any reliable transport works theoretically, yet for all practical purposes of IP networks, this usually implies TCP.

Tobi Nary
  • 14,302
  • 8
  • 43
  • 58
  • Thank you especially for your second paragraph. I think I can use that as an answer, should the professor ask. – UTF-8 Oct 07 '17 at 15:52
  • 1
    Someone said this in a past exam: "A reliable connection is required because if a ChangeCipherSpec gets lost, the connection can continue without the cipher suite being applied." Sounds completely wrong to me. Can you please tell me whether you agree with me or him? – UTF-8 Oct 07 '17 at 15:57
  • 1
    The connection would rather end to work for both parties, as they do not use the same cipher from that loss onwards and would not be able to convey actual, useful information - the layer 7 protocol would not like that, probably. So the connection might not fail instantly, but eventually. – Tobi Nary Oct 07 '17 at 16:02
  • That's what I thought. Sounds more convincing. Does the client wait for the server's "finished" message when establishing a connection or may the client send the first payload data immediately after sending its own "finished" message? I'm pretty sure it waits because otherwise the protocol seems like it could be attacked, but I want to be sure that's actually how it works. – UTF-8 Oct 07 '17 at 17:06
  • 6
    @UTF-8 If that was true, then TLS wouldn't be secure because TCP isn't. If it relied on TCP's security to provide its own, it wouldn't be more secure than TCP. – David Schwartz Oct 07 '17 at 23:51
  • @DavidSchwartz Apparently, this actually was an attack. It's called "ChangeChipherSpec Drop" and I just posed [this question](https://security.stackexchange.com/questions/170893/why-did-changechiperspec-drop-work) about it. – UTF-8 Oct 08 '17 at 18:07
  • @UTF-8 TCP won't help, since it's not "reliable" against an adversary. – David Schwartz Oct 08 '17 at 20:14
  • There's actually TLS over UDP, called DTLS - Datagram Transport Layer Security. It's seen commonly in IoT applications to mitigate sniffing and manipulation of traffic. – h4ckNinja Oct 08 '17 at 22:48
  • Also don't forget about flow control - TCP throttles the stream of user data to match the connection bandwidth – Nayuki Oct 10 '17 at 16:04
  • @Nayuki that is no requirement of TLS, yet it helps with reliability. No flow control might dos the other side - but as long as the protocol still maintains a reliable transport, flow control is not necessary. – Tobi Nary Oct 10 '17 at 16:09
  • I mean to imply that if TLS is not built on top of TCP, then it would need to implement its own flow control, which is extra complexity – Nayuki Oct 10 '17 at 18:26
40

TLS does not require TCP, it only requires a reliable transport. There is even a standard for TLS over SCTP which is another reliable transport protocol.

But, if you take today's internet then you usually only have UDP and TCP as transport protocols on top of IP and from these two TCP is the only reliable one. Which means, if you have only this limited selection of transport protocols available then TLS requires TCP because it does not work with UDP. To work with UDP there is a similar protocol DTLS which is designed to work over unreliable transports.

Community
  • 1
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
12

In addition to what others have already said, TLS requires a reliable transport layer protocol because it requires that all of the data packets be received, be received in order, and be received uncorrupted. There are several reasons for this:

  • If a packet were dropped or corrupted, TLS would have no way of recovering the data from that packet to present to the application layer and, thus, the assumption of reliability presented to the application layer would be lost.

  • If a packet were corrupted, even by a single bit, it would likely be completely garbled due to the encryption, particularly if a block cipher is in use.

  • If a packet were lost, corrupted, or processed out-of-order, any encryption scheme based on Cipher Block Chaining would not only fail to decrypt the current block, but would also fail for every block after it, since each block depends on the block before it (and, thus, on all previous blocks.) Thus, any packet error on the network at all would require the TLS connection to be torn down and renegotiated. Cipher block chaining XORs the plaintext for a cipher block with the ciphertext of the previous block prior to encrypting it in order to prevent someone monitoring the ciphertext from being able to detect patterns of duplicate plaintexts from the ciphertext.

  • If a record were corrupted, even by a single bit, the Message Authentication Code would not match, causing TLS to (correctly) think that the message had been altered in transit, which would result in the TLS connection being torn down.

  • If a record were received out-of-order while a stream cipher were in use, the portion of the message in that record would be decrypted incorrectly (using the wrong portion of the stream) and, thus, the MAC check would fail and the TLS connection would be torn down.

Of course, TLS itself will work fine as long as the underlying transport protocol provides the guarantee of reliability. There's nothing within TLS itself requiring the underlying transport protocol to be TCP. Of course, TCP is generally the reliable protocol of choice where the Internet is concerned.

reirab
  • 2,683
  • 1
  • 13
  • 21
  • 2
    Small nit - UDP do have checksums as do TCP so any random alterations (cosmic ray) should be detected. Lower level protocols in stack might employ CRC allowing to detect AND correct errors. I don't think there are any protocols which do not have this feature (anything running on top of Ethernet, PPP... already has it). 'Unreliable' here means that packets can be dropped (out of order is handled in for ex. SCTP extension). Of course it does not protect against malicious changes - for that you need TLS or something similar. – Maciej Piechotka Oct 09 '17 at 15:58
  • @MaciejPiechotka Yes, I'm aware that UDP has a checksum and am aware of the CRC in the Ethernet frame. I was only describing in general why TLS needs reliability in the underlying transport protocol. – reirab Oct 09 '17 at 16:43
3

TLS does not require TCP. For example I use a TLS authentication key with OpenVPN which (per my configuration to lower overhead) goes over a TUN interface which rides on UDP. TLS can be used on both, and probably on top of other things I'm not aware of.

Marshall Whittaker
  • 183
  • 5
  • 4
    This answer is wrong. OpenVPN always uses TLS over TCP to authenticate and exchange session keys. The bulk data can then be transmitted over UDP or TCP, until a new session key is needed which will again be exchanged over TLS over TCP only. Never is TLS used over UDP! – Josef Oct 08 '17 at 19:15
  • 2
    @Josef, This is wrong. When OpenVPN is configured to use UDP, it does not use TCP at all: you can check that by running a UDP OpenVPN server; there is not associated TCP socket. TLS is used over UDP. More precisely, a reliability layer is used to provide reliability over UDP and TLS runs on top of that : https://build.openvpn.net/doxygen/html/group__reliable.html#details – ysdx Oct 09 '17 at 07:27
  • 3
    @ysdx Then it doesn't run on UDP, it runs on the Reliability Layer that runs on top of UDP. – zakinster Oct 09 '17 at 09:18
  • 2
    @zakinster, yes of course TLS is not ised directly over UDP. But claiming that "OpenVPN always uses TLS over TCP to authenticate and exchange session keys. [...] Never is TLS used over UDP!" is not correct. – ysdx Oct 09 '17 at 10:59
  • The answer is at least unclear. `TLS can be used on both...` suggests that you were able to replace the underlying TCP by UDP. That's definitely wrong. – blafasel Oct 11 '17 at 09:39