A tunnel is used to bypass restrictions on a system. In the case of an SSL or TLS tunnel, you would try to bypass restrictions by encrypting the communication.
For example, suppose your organization has a rule that no .exe files should be downloaded from outside sources. By setting up an SSL or TLS tunnel, you could download a .exe file, and it would be encrypted during transfer - so if the network is monitored, the .exe file won't be spotted.
(Obviously the organization should have more defenses against foreign .exe files, and employees with a better sense of responsibility - but that's beside the point).
You could make it impossible to use SSL/TLS traffic on your network, but that is often not an option in practice - it would also hamper the many legitimate uses of SSL/TLS, like logging on to webmail.
You could restrict the hosts to which SSL/TLS connections could be made, although determining which hosts should be allowed is likely to be a lot of work.
In response to your update: without access to at least some of the organization's infrastructure, the attacker cannot set up the receiving end. But "access" is a broad concept here: if the attacker can trick an employee, for example by making a genuine-looking website, that is enough.
The defense here are the certificates that SSL and TLS use to prove one's identity. The risk is that people may not pay attention to security warnings about certificates, or that a root certificate is compromised (e.g. DigiNotar).