Is it not true that SSL can be decrypted by simply having listened to the network activity of a PC on a network? (for example, from the first time a random PC connects to a coffee shop, and keep listening until the user stops browsing and you no longer care for further data) Aren't all the keys there and the algorithms published so that it can be decrypted without any brute force?
(This is a yes or no question, but citing a source would be nice for furthur reading)
The short answer to your question is, in the general case*, no.
The longer answer is that the reason that this is not possible is largely to do with the use of Public-Private key cryptography in the establishment of the SSL session which means that the session key is not transmitted over the network in the clear at any time during the session.
*There's a variety of sets of circumstances which may result in someone being able to decrypt an SSL encrypted communication but they're unlikely to apply to the general coffee shop scenario.
You can create a common shared secret without transferring it over the network. Read on RSA and Diffie-Hellman key exchange in Wikipedia or other sources to get an intuition on how this works. You can even do a simple test computation by yourself (but it is only secure for extremely large numbers and several minor modifications).
Once you understand this, you may want to have a look at the (equally simple) Man-In-The-Middle attacks against these algorithms (probably also on wikipedia). To prevent these, you need mutual authentication, e.g., by signing the DH/RSA public keys and letting the peer verify the signature.
This authentication in turn requires some common knowledge from the "signature issuer"(certification authority), but that information is not required to be secret. This final ingredient("root certificate") is thus simply shipped with each browser and there are extensive procedures for creating and accepting it.
So, as long as you trust these authorities whose root certificate your browser vendor put into your browser to issue correct authentication information(certificates), you will be able to create encrypted+authenticated connections. (encryption is close to useless if you don't know where you're connected to!)
SSL cannot be decrypted by the method you mentioned.
However, what you described is similar to an attack on a wireless network key such as WEP.
The private key of the server is never transmitted. This means that the client can send information encrypted with the public key of the server and only the server can decrypt it. This information will result in a session key that is only known to the client and the server and will be used to encrypt the traffic.
Note: This is an extremely simplified summary. There is a lot more "magic" going on to ensure that your are using the public key of the right server and the traffic cannot be replayed.
Wikipedia has a good article able Public/private key cryptography
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.
