Why can protocols on higher layers be left unchanged?

Question

In his answer to "How does SSL/TLS work?", Luc gives an explanation of how SSL works:

SSL (and its successor, TLS) is a protocol that operates directly on top of TCP (although there are also implementations for datagram based protocols such as UDP). This way, protocols on higher layers (such as HTTP) can be left unchanged while still providing a secure connection. Underneath the SSL layer, HTTP is identical to HTTPS.

In his first sentence, he is saying that protocols on higher layers can be left unchanged.

What does he mean? I know the OSI layers, but I think I've got some knowledge issues here.

Answer 1

You should think of OSI layers as packaging.

Let's say I want to ship a glass to you. I chose an original package for advertisement purposes, showing how nice is my product and what you can buy to add to your "glass" experience. That's the high layer of my protocol.

Then I put this package in a box filled with soft thingies because I don't want it to be broken by transportation. This is a second layer.

Then my shipment department enclose this box into a bigger package, with a label to be shipped to your home. Again, another layer.

Then the transporter put this box in a truck with many other boxes and instruct the driver to go to another delivery center, again another layer.

For what we know, the truck driver does not need to know :

• where do the boxes go exactly in your home, he just needs to know your address
• what protection are in the boxes, he just has to drive as safely as it's instructed in his contract
• what exactly is in the boxes

Let's say now that I want to provide confidentiality to my shipment. Because, a curious driver could try to tamper with the packages to know what's inside, or steal it and resell it.

I can use a protocol where your packaged-soft-coated glass is also put into a metal box with a locker. It will protect it from tampering by the truck driver, as he won't be able to peek inside, or take the merchandise. It does not protect the lower layers, he could still dump all the fret into a lake, this is denial of service. Moreover, my locker does not care what's inside it. It could be your glass, it could be flowers or it could be empty. But it still serves the purpose of avoiding anyone other than you (and the shipper ofc) to know what is inside.

It goes the same for the protocols in the OSI. Lower layers does not care about what is happening in the upper layers. This is left for another agent to decode/handle it.

Edit for clarification: when we say "left unchanged" it does not mean the information is not processed. For SSL in particular, the payload of the SSL layer is an encryption of the packet of the higher layer. But when SSL operated in the other side, it will decrypt the original packet with no modification.

Answer 2

While OSI is just a model, and in reality the layers can be blurred or nonexistent, the concept of layering protocols is specifically to allow a change in a particular layer to leave the layers above and below it alone.

As an example:

• Physical - does a basic packet care whether it is travelling over copper, fibre or wireless? It could travel over all three at some point in its journey. You don't want to have to rewrite http in specific flavours for each of these physical media, so you do it once.

So the important pieces are how each layer interfaces with the adjacent ones.

@M'vy's metaphor of transporting a physical item is very appropriate here.

Answer 3

TCP provides to applications a stream interface. There are a few exceptions where the details leak through, but generally a TCP socket is opened, and then each side sends a series of bytes to the other. Those bytes will be delivered intact and in order, up until the point where the remote end closes the connection (which you will be informed of). Applications only need to know about the stream interface. They don't need to know about the details of the underlying network hardware, they don't need to know about congestion control, window sizes, retransmission of packets, or even that there are packets.

TLS sits on top of TCP, and provides authentication and encryption services, and it also provides to applications a stream interface. There's a bunch of additional stuff going on under the hood, a bunch of new potential error conditions, and a bunch of new metadata that an application an query a socket for (for example, information about the remote certificate and its issuee), but the basic operations are the same — connect to a given address, send bytes, receive bytes, close connection, and be informed of a remote close.

The point of this is that any application-level protocol that can operate on top of the streams provided by TCP can also operate on top of the streams provided by SSL, without any fundamental change to the application itself. In fact, in cases where it's not considered important that the application receive information about the encryption used, or the remote party's certificate, or any of that, you can use a proxy like stunnel to translate between a TLS-encrypted TCP connection and an unencrypted one. For example, stunnel on a client machine could allow a regular (non-TLS-supporting) mail client pointed at the IMAP server localhost:143 to connect to the IMAPS server mymailserver:993; or stunnel on a server machine could listen for HTTPS connections on externalip:443 and proxy them to internalserver:80, allowing internalserver (an HTTP server) to have secure communications with the world even though it doesn't implement TLS itself.

Answer 4

This is just like moving vehicles on the road. Like road is the fixed medium and on it many types of vehicles can run and so if you make new vehicle for it to run on road the vehicle must have tyres that could run on that road.

Similarly if you consider Ethernet as one medium it could carry various networking protocols like IPv4 or IPv6. So the point over here is that networking model is made so modular that you can replace things as you like as long as they do comply with certain interface specifications.

So modular design specifies that whatever be your internal working does not matter what matters that you are given input in certain way process on it and generate an output understandable by next module.

Answer 5

After establishing a secure connection, a web browser will still ask the same type of question such as

GET /som/page.html HTTP/1.1
host: www.example.com

and the web server will still respond the same way

200 OK
Content-Type text/html
...

The only difference is that underneath this conversation we do not have a straight TCP connection but instead encryption. Just like the higher layers are "unaware" of what TCP normally does (such as packet retransmission, acknowledgement, window adjustment, ...), they are also "unaware" of the underlying encryption taking place.

Well, strictly speaking there is some interdependency: The encryption layer is built upon the usage of a certificate belonging specifically to the FQDN www.example.com, which traditionally the server does not know about until receiving the host: header. That's also why older implementations could deal with multiple http-vhosts on a single ip, but only one https-vhost per ip. This was remedied by SNI.

Answer 6

High level protocols may not be secure when used, unchanged, with SSL. There is a possibility of side channel attacks.

As others have explained well, SSL allows you to wrap an unencrypted stream in an encrypted one. In theory, no information about the data being transmitted should be leaked. In practice, there's one piece of data that always leaks - the amount of data transmitted.

This sounds like an acceptable leak, and in some cases it is. However, there are a number of attacks, such as the CRIME attack, and this attack on VOIP, which take advantage of the fact that data is compressed, and compression ratios vary depending on the message content, to glean information about the content of messages.

Other side channel attacks may also be possible using other pieces of leaked data, such as the precise timing of requests and responses.

Answer 7

Http                    Https

+------------------+    +------------------+
|7 http  methods   |    | http methods     |  <---same No change needed
+------------------+    +------------------+
|6 data:ex)"$1000" |    | data:ex)"kf4d3s1"|  <---data encrypted
+------------------+    +------------------+
|5 Sock:           |    | Sock:            |
+------------------+    +------------------+
|4 TCP :           |    | TCP:             |
+------------------+    +------------------+
|3 IP :            |    | IP :             |
+------------------+    +------------------+
|2 PPP:            |    | PPP:             |
+------------------+    +------------------+
|1 RJ45:           |    | RJ45:            |
+------------------+    +------------------+


7.  Application Layer  -> Http
6.  Presentation Layer -> MIME SSL TLS XDR <---- This is what you want
5.  Session Layer      -> Sockets
4.  Transport Layer    -> TCP UDP SCTP DCCP
3.  Network Layer      -> IP IPsec ICMP IGMP OSPF RIP
2.  Data link Layer    -> PPP,SBTV,SLIP
1.  Physical Layer     -> FDDI, B8ZS, V.35, V.24, RJ45.

Only the ways of negotiate/handshake change for added encryption.

HTTPS encrypts an HTTP message(data) prior to transmission and decrypts it upon arrival

Answer 8

I know the OSI layers

OK, first mistake there - but as you've seen from the other answers, this is a common misconception. TCP/IP is not OSI. It predates OSI but a number of years. And its not even intended to be the same thing. TCP/IP is (some of the layers of) a networking protocol, OSI is a model of how to design a full network protocol. Try to explain TCP/IP in terms of OSI and you're going to come unstuck very soon e.g. HTTP/2 over TCP/IP? 4 different session layers, compression done in at least 2 separate layers of the stack.

SSL or TLS is a method of implementing asymmetric communication over any bi-directional stream interface. That means it can run on TCP/IP, IPX/SPX, Unix domain sockets, (full duplex) named pipes, RS-232.... But when was the last time you used a data network other than TCP/IP?

Luc is not wrong in saying that SSL/TLS can run on top of UDP, he's just not telling the whole story - for such an architecture there is additional layer between the TLS and UDP parts which implements stream reassembly, error recovery and bandwidth management.

Answer 9

Higher-layer protocols don't bother with the details of lower layers. They just assume that the lower layers have been implemented in some fashion, and proceed from there. If we go by the TCP/IP model, there are four of these layers:

OSI defines a Physical layer, which handles connecting two machines together; TCP/IP doesn't, but it's useful to think about here. Twisted-pair, coaxial, CAT6, and radio waves are some common ways to connect machines, but you can use almost anything, including laser beams, sound waves, and, yes, carrier pigeons.

The Link layer, which handles getting a signal across two directly-connected machines. The 802.11 family (Wi-Fi), the 802.3 family (Ethernet), and PPP (modems) are probably the most popular link-layer protocols today, but there are others.

The Internet layer, which gets a signal across two machines that aren't directly connected through a chain of machines that are. This is where IP lives, both in IPv4 and IPv6.

The Transport layer, which handles the logistics of turning signals into a usable stream of data. TCP and UDP both live here, as do some lesser-known protocols.

The Application layer, which interprets the data assembled by the Transport layer. This is where most of the protocols we commonly hear about -HTTP, FTP, POP, IMAP, and so on- live.

HTTP lives in the Application layer. It assumes that you already have a meaningful way to get a stream of data across machines that might not be directly connected to one another. As long as you've got that, HTTP doesn't care where the data stream comes from. Technically you don't even have to use TCP/IP in the underlying transport, though in practice almost everyone does.

For everyday purposes, SSL/TLS lives in the Transport layer (the technical truth of the matter is more complicated, but it doesn't affect end users). That is to say, you give it a stream of data to send, and get back a stream of data when you receive, just like TCP/IP. Notably, SSL/TLS doesn't care about the contents of its data stream: you can pass it whatever you want, and it will do its thing.

Because neither layer cares what the other one does, you can swap them out freely. HTTP is happy as long as it gets the streams it wants, and doesn't care what the underlying protocols do to those streams in the meantime, so you can use any transport-layer protocol underneath. TCP/IP (and SSL/TLS) don't care about the contents of the data, except as necessary to make sure that the resulting data on the other end looks exactly the same as what the user sent, so you can use any application-layer protocol with them

Answer 10

In his first sentence, he is saying that protocols on higher layers can be left unchanged.

This is false, period.

Higher layers need to indicate in some way that SSL/TLS should be used; in the Web this is done with the HTTPS: URL scheme, with the secure flag on HTTP cookies and with an HSTS (HTTP Strict Transport Security) policy.