The magic that prevents an attacker to decrypt all the data this way is called "asymmetric cryptography". Because the encryption key and decryption key do not have to be the same, it is possible to send one of them in the open, thus allowing everyone to encrypt future messages to you, and still retain the exclusive ability to decrypt them (the other, private, key of the pair). Those keys are different (freshly generated) in every SSL session.
It gets more complicated when the attacker is willing to actively send out "false" keys, tricking others to use them. So the other topic that you might want to read about is "public key infrastructure". This provides an initial level of trust based on previous communication behind the scenes, between parties such as certificate authorities, server operator, hardware manufacturer, and operating system vendors. Already before the first packet is transmitted inside the coffee shop, everybody holds various certificates and keys and contacts to mutually trusted friends all of which will come handy in authenticating the other party for who they say they are.
SSL can autheticate both servers and clients, but because the server has more control over the session key, and also over the business logic of the interaction, it's common not to bother to authenticate clients.
You can occasionally run into scenarios where the normal assumptions break down. Logic errors in protocols, incompenent CAs, government interference, factory-compromised hardware, keys that have leaked without anyone noticing, and random key generators that are much less random than you'd like. For the vast majority of such holes, the privacy in the coffee shop is only at risk if the attacker actively interferes and helps steer the conversation toward the hole somehow.