18
$\begingroup$

Protocol stack diagram showing SSL above TCP

Why is SSL not under TCP (the Transport layer)?

Improve this question
$\endgroup$
0

8 Answers 8

Reset to default
25
$\begingroup$

why the SSL is not under the TCP ( Transport layer ) ?

Because SSL can use TCP [1] to transport SSL records, and so SSL relies on TCP as a service.

That is, SSL takes the user data stream, and converts it into a series of records; it then gives these records to TCP to transmit. On the other side, the receiver's TCP stack gets these records and gives it to SSL to decrypt.

Similarly, TCP takes the data it has been given, and converts it into a series of segments; it then gives these segments to IP to transmit (hence TCP is shown on top of IP).

[1] There's no requirement that SSL has to use TCP; it's just what is used in practice.

Improve this answer
$\endgroup$
2
  • 4
    $\begingroup$ Indeed. It has even been adapted to UDP; see DTLS. $\endgroup$
    – Michael Hampton
    Dec 9, 2017 at 7:09
  • $\begingroup$ Excellent note about no requirement for SSL to run over TCP. Just because it's almost always done that way, it's not a requirement. In the embedded systems world, I've seen SSL (well, TLS) run on top of other communications stacks. $\endgroup$
    – Dan
    Mar 21, 2018 at 0:03
12
$\begingroup$

The Secure Socket Layer is as the name suggests build on sockets, which provide error free, ordered stream of data. TLS is the differently named successor to SSL; TLS 1.0 succeeds SSL 3. TLS likewise is named Transport Layer Security. TCP is the transmission control protocol that is build on top of IP to provide this transport layer.

TLS requires two reliable, error free, ordered streams of data to operate - it provides two secured streams in return. TLS works well on any reliable, ordered stream, not just TCP. It's just that TCP is the most common streaming protocol at the transport layer of the Internet. The internet protocol (IP) by itself doesn't provide this streaming capability; it only specifies how to route individual packets.

Note that SSL is used to protect the transport layer of many internet protocols. These protocols are handled by the various services on the internet. So having security at this level means that SSL provides application specific security; each port can be secured, sometimes even after the protocol has started (STARTTLS on mail connections, for instance).

There is also a version of TLS called DTLS which operates on UDP; UDP offers unordered data packets and DTLS can be used to secure those packets. And IPSEC has already been named which can be used to implement security at the internetworking / datagram level.

You are currently likely using the secure version of the cryptography site, which uses HTTPS, HTTP over SSL on a TCP socket connected to port number 443 on the application server (or by a proxy or SSL accelerator in front of it).

Improve this answer
$\endgroup$
10
$\begingroup$

While the other answers are good, I think they're missing the core point: TCP is what's there. You can't just define arbitrary new layer-4 protocols on top of IP and expect existing operating systems and network equipment (especially: think NAT) to handle them. By doing SSL on top of TCP, you make it so it works anywhere TCP can work, and so that it's not blocked, intentionally or unintentionally, without some sort of deep packet inspection that violates standard network semantics.

Improve this answer
$\endgroup$
12
  • $\begingroup$ Mmm, normal NAT should actually handle a new layer-4 protocol fine since that's layer 3 tech unless you are doing port rewrite as well. Most network equipment should pass it ok unless there's some kind of filter rule in place to block unexpected protocols. The operating system is the big problem, you have to implement a nonstandard protocol via raw sockets and your own frame handling code, without any of the help and security the OS normally provides. $\endgroup$
    – Kaithar
    Dec 8, 2017 at 22:37
  • 1
    $\begingroup$ NAT has to do port rewrites. $\endgroup$
    – R.. GitHub STOP HELPING ICE
    Dec 8, 2017 at 23:26
  • $\begingroup$ @R Hmmm, I would say rather that it's not that it has to but that it's considerably less useful without the protocol helper. Something like a 1:1 NAT wouldn't need it, and you could probably dodge it if you can encode the flow identification in to the IP headers. $\endgroup$
    – Kaithar
    Dec 8, 2017 at 23:44
  • 1
    $\begingroup$ Hosts behind the NAT have no way to know about each other or negotiate which ports they use, so they can and will use overlapping port numbers for outgoing connections, possibly even to the same remote peer (especially for popular sites). There is no solution without remapping ports not to clash. Note that I'm assuming you only have one, or a small number, of public-facing IP addresses; if that's not the case you don't need NAT. $\endgroup$
    – R.. GitHub STOP HELPING ICE
    Dec 9, 2017 at 1:23
  • $\begingroup$ SSL predates the common use of NAT by many years. $\endgroup$
    – rmalayter
    Dec 10, 2017 at 12:11
4
$\begingroup$

Hysterical raisins.

It was an unfortunate design decision, because it built denial of service into the protocol with unauthenticated RST packets. But it was expedient because TCP is ubiquitous and deals with things like packet reordering congestion control.

Modern protocols like CurveCP, MinimaLT (paywall-free link, with reference), and QUIC sensibly operate at the packet layer and incorporate congestion control and cryptography to deal with the denial-of-service vector. Unfortunately, in the two decades since SSL was created, TCP has become still more ubiquitous and more and more middleboxes have gotten in the way of UDP-based protocols or custom IP protocols.

Improve this answer
$\endgroup$
0
3
$\begingroup$

Realistically, if you replaced TCP with something like SSL you'd have to re-implement TCP in your new protocol anyway.

TCP handles packet order, service selection, data stream association, retransmission, error detection, flow and congestion control... you'd have to do all of that in your new protocol, otherwise it wouldn't be reliable. If you're already re-implementing most of the features and overhead of TCP you might as well use TCP and save yourself the hassle and security implications of repeating work.

Plus it automatically has some compatibility with anything that works on TCP already, and putting it over TCP means you can start a connection in clear and then switch to encrypted if both ends support it (see STARTTLS).

Improve this answer
$\endgroup$
2
$\begingroup$

Same reason the road doesn't go on top of the car. The Road has no purpose other than to provide an acceptable medium for vehicles such as a car to move along.

Improve this answer
$\endgroup$
2
$\begingroup$

The "below TCP version of SSL" is IPSEC.

IPsec is an end-to-end security scheme operating in the Internet Layer of the Internet Protocol Suite, while some other Internet security systems in widespread use, such as Transport Layer Security (TLS) and Secure Shell (SSH), operate in the upper layers at the Transport Layer (TLS) and the Application layer (SSH). IPsec can automatically secure applications at the IP layer.

Improve this answer
$\endgroup$
2
  • $\begingroup$ ...or rather DTLS. $\endgroup$
    – Henrick Hellström
    Dec 8, 2017 at 13:24
  • 6
    $\begingroup$ @Henrick: I thought DTLS was the UDP variant of TLS (the "TCP" variant). So I'd consider that "next to" TLS/TCP, not "beneath". DTLS is to UDP, what TLS is to TCP: extra upper structure. But at a point, this is probably semantically nitpicking. $\endgroup$
    – entrop-x
    Dec 8, 2017 at 14:20
1
$\begingroup$

You can use the analogy of shipping to describe how SSL works. TCP would be a wagon that carries information. SSL will wrap that information in a locked safe before it gets put on the wagon. But without the wagon, it's not going anywhere.

But without a driver, the wagon can't be trusted to get where it's going. So the wagon is "IP", the driver is "TCP" and the locked safe is "SSL"

Improve this answer
$\endgroup$

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