Generally, a symmetric key is negotiated on the fly, and securely exchanged between the browser and the server. One protocol that enables people to do this (Diffie-Hellman key exchange) is explained in this excellent youtube video: http://www.youtube.com/watch?v=3QnD2c4Xovk.
The random data for that is derived using any number of methods; it's certainly not static, and it generally won't have much to do with the current time. The classic example is to use the number of microseconds from the time, which is something that knowing the time of day to the second won't help. Other sources include the timing of certain events (keypresses and disk accesses, as common in linux), the number of photons reflected by a semitransparent mirror at some moment (quantum-derived entropy like many SSL accelerators use), or the action of a metastable oscillator (the intel DRBG), and several other things. This random data is collected each time it is required, though in practice it can sometimes be stored in a pool for later use (which can be a vulnerability also, but that's another topic).
Since the key is quite random, you need to do a lot of bruteforce to get it. If you maximized the amount of entropy you could use for your key, and the cipher used a 256-bit key (AES-256, etc.), you would have to try a lot of times (2^256 * 0.50 attempts would give you a 50% chance of recovering the key). In practice, a lot of people use less entropy than this and construct the rest of the key deterministically, which means that if they used only 64 bits of entropy that formula would change to 2^64 * 0.50, as long as you knew exactly how the key was being generated. For DH key exchange like I mentioned above, the math is actually a little more complex because you have to account for the fact that you're choosing two random numbers and not one.
This is a lot of keys, and the odds of most attackers breaking one by bruteforce before you've stopped using it are very minimal.
