This is an often misunderstood feature and I’ll try my best to explain it briefly.

I’ll be using three computers designated as client, destination and ssh-server.

client
The client computer witch runs all the commands and uses the tunnel afterwards

destination
Where the client would like to connect to

ssh-server
A computer running ssh daemon where the client has access.

The Scenario
The client would like to connect to destination, but for some reason is unable to. Maybe a firewall is preventing outbound traffic to that port, or maybe the destination is restricting ip address that can connect. There are many reasons why going through a third party can be usefull.

The solution
ssh -L 5050:cnn.com:80 bob@ssh-server

This command will bind the local client port 5050 through an encrypted tunnel ending up at the ssh-server. Using bob as the username to gain access to the ssh-server. Communication from ssh-server to the website will not be encrypted, as it is no longer inside the tunnel. To specify further; communication will not be encrypted by the ssh-tunnel, but if the communication was already encrypted on the client before entering the tunnel, it would still be when leaving ssh-server.

The destination will only see a connection from ssh-server, even if it originated from the client.

So http://localhost:5050 on the client will now show cnn.com. Although tunnelling to a website is a bad idea, because a webpage usually requires many other sites (content, script and stylesheet may be hosted on a subdomain or simmilar), and may try to redirect to other port or addresses. But it illustrates the point.

ssh on non-standard port
What if the ssh deamon is listening on a different port?  say port 2022.
just add -p 2022 like this:

ssh -L 5050:cnn.com:80 bob@ssh-server -p 2022