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.

  • 1
    Which part of "layer" is unclear to you?
    – Shadur
    Feb 10, 2015 at 11:41
  • 7
    FYI, since it seems that they have been teaching you this for a while and never yet mentioned it: the OSI model is largely academic, if not theoretical. The TCP/IP model is NOT OSI, nor does it fit nor apply. When trying to understand real-world networks, I'm afraid you need to unlearn all you've learnt about OSI - with the exception of the concept of layer encapsulation, which is the same (and what you're basically asking about here).
    – AviD
    Feb 10, 2015 at 14:42
  • @Avi Even with layer encapsulation, my understanding is that TCP/IP is less strict about it than OSI is (a higher-level protocol might well care about what lower-level protocol it's being used on).
    – cpast
    Feb 10, 2015 at 16:36
  • @cpast yeah, the implementation of that is different too. I just meant that the concept is the only thing that carries over.
    – AviD
    Feb 10, 2015 at 16:47

10 Answers 10


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.

  • 2
    Well after almost 2 month of learning OSI layers in school it finally made click, thank you! :D
    – Octfx
    Feb 10, 2015 at 13:38

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.

  • 2
    Speaking of which has anybody tried to send a torrent via carrier pidgeon yet ? There is a official rfc for using them as the transport layer . Apparently the ping time is terrible but the packet loss is surprisingly low. Feb 9, 2015 at 17:32
  • 13
    It has been done for large files: The Hungry Beast team transfered a 700MB file via three delivery methods to determine which was the fastest; A carrier pigeon with a microSD card, a car carrying a USB Stick, or an ADSL line over 132km by road. The pigeon won the race after 1 hour 5 minutes, the car came in second at 2 hours 10 minutes, while the internet transfer did not finish (estimated time to upload completion at one point was as high as 9 hours)
    – Rory Alsop
    Feb 9, 2015 at 18:19
  • Make that +2, I wasn't aware that this was repeated and documented after the 90s Feb 9, 2015 at 18:24
  • @DamianNikodem People have sent files over carrier pigeon, but other than a joke it hasn't been done using IPoAC (which is what I think you're talking about) -- IP works great with a low-latency connection, but terribly with a very-high-latency connection. I think pigeons have been seriously used as a sneakernet transport method (like by naturalists in remote places), but you wouldn't send IP traffic via them.
    – cpast
    Feb 10, 2015 at 16:43
  • 4
    @DamianNikodem That RFC was the original joke, actually - check the date. AFAIK, IPoAC didn't exist as a concept until the RFC (which is not a standards-track RFC, incidentally: it's experimental and not recommended and also a joke that is not meant to be taken seriously). There is practical use for carrier pigeons to transfer data, but IPoAC is not it (you want to just stick all the data on storage media, instead of splitting into IP packets).
    – cpast
    Feb 10, 2015 at 20:13

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.


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.


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.


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.

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

  • check this : slideshare.net/vikramsinghamit/http-vshttps
    – ganesh
    Feb 11, 2015 at 10:18
  • So plain HTTP (without SSL/TLS) has an empty presentation layer? Feb 11, 2015 at 18:41
  • 6. Presentation Layer -> MIME SSL TLS XDR <---- This is what you want. SSL/TLS in only a part of PLayer. (TLS ->Expands as transport layer security but shown in PLayer?). The presentation layer is more concerned with marshalling data into non-network-dependent formats and interpreting it on the host side through the appropriate application Pls refer this too! security.stackexchange.com/questions/19681/… (comments of answer).
    – ganesh
    Feb 13, 2015 at 5:03

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


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.


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.

  • 1
    Not necessarily; this is more of a practicality than an actual requirement - I could just start an ordinary web server behind OpenSSL, GnuTLS or similar, you could point your ordinary web browser through same, and neither program will be any the wiser that it's encrypted. HTTPS, IMAPS etc. are just codifications of this process.
    – felixphew
    Feb 11, 2015 at 20:17

You must log in to answer this question.

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