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