Yes and no. To understand why, we need to look at the way the Internet is structured.
The Internet is not made up of a single protocol, but a number of protocols that stack up on top of each other. You can classify protocols according to where they fit in the stack, and the themes that emerge when you do this are called layers.
There are two competing models for how this works, and I'm going to briefly talk about the lowest layer of the OSI model: this is not the model that the IP folks use, but it gives us some interesting grounding. The very lowest level, according to the OSI folks, is the physical layer: the actual thing you use to send signals. Chances are that the physical layer your computer is using right now is either "a copper wire" or "radio waves", but there are others: in the past people have used fiber-optic cables, sound waves, laser beams, and so forth. As an April Fools' Day joke, someone even came up with a way to do it with carrier pigeons, and while that's not something anyone would want to use, it really does work.
The lowest model used by the TCP/IP folks (second-lowest in the OSI model) is called the link layer. The physical layer gives us a direct connection between two machines, but it doesn't say anything about how to get a signal across that connection: this is what the link layer is for Ethernet is a common link-layer protocol nowadays for machines that are permanently connected via cables, and Wi-Fi (which is derived from Ethernet) does the same thing for radio waves. PPP is the most popular link-layer protocol for modems these days. There are other link-layer protocols too.
But what's really interesting for this question are the second and third layers. The second layer is called the network layer or internet layer (note the small I; this is not the same thing as the Internet). This is where signals live that try to get a signal between two machines that aren't directly connected, using a chain of machines that are directly connected. IP, the Internet Protocol, lives in this layer; it's where IP addresses come from.
The third layer -the transport layer- is where we stop talking about signals and start talking about data: given the signal, we begin to make something coherent out of it. If you've heard of TCP and UDP, this is where they live: TCP lets you chain packets together into sessions, while UDP is a more low-layer protocol for those times when TCP's infrastructure isn't really needed. The job of the transport layer is to get the hosts on either end of the connection talking in a coherent way.
The fourth layer -the application layer- is where most of the exciting action takes place: it builds upon the transport layer's infrastructure to accomplish what we typically think of as networking tasks. HTTP, the protocol that the Web is built on, lives in this layer; so do the FTP and BitTorrent file-transfer protocols, the SMTP/POP/IMAP trio of e-mail protocols, the IRC chat protocol, and many others.
TLS (and its predecessor SSL) live in the Transport layer. TLS even gets its name from there: Transport Layer Security. It provides a common infrastructure for application-layer protocols, like HTTP, to talk to each other, and for this, it works well.
Because TLS encrypts HTTP, it (theoretically) protects data such as the URL. However, you still make that request -including the IP address of the server you connect to- through IP, and TLS lives too high in the stack to encrypt that. So if you request a site from the same host that the site is on, the NSA (or some other agent) could figure out the host you were connecting to by looking at what you were sending in the internet layer. They cannot get the rest of the URL, because that's handled inside of HTTP (which TLS encrypts), but they could get the host.
If you're using HTTP tunneling, you can partly get around this. If you tunnel one HTTP connection through another HTTP connection, then you don't connect directly to xsite.com or ysite.com: instead you connect to zsite.com, tell it you want to connect to these other places, and it will make the request for you. Because HTTP tunneling lives in HTTP, TLS will protect it: the NSA could detect that you connected to zsite.com, but they wouldn't be able to tell anything else, including what sites you asked zsite.com to connect to. Of course, eventually they'll catch on and start looking at what zsite.com does, but first they have to notice.
None of this goes into the practicality of breaking TLS. I'm just trying to give an overview of what TLS can protect (as long as it holds), and what it can't protect even if it works perfectly.
1.DNS request.2.DNS reply.3.SSL client hello.4.SSL certificate. – kasperd Jan 08 '15 at 22:17