There's a few ways this can work. But this gist is that your asymmetric keys are used more for identity validation rather than encryption. While typically only the server needs to verify its identity, sometimes the server can request that the browser identity itself back using a client certificate. Try it out here if you like.†
†: Startcom is a certificate authority famous for providing free certificates, but for also having a website so totally unusable that people actually pay for certificates anyway, just so they don't have to use startcom's site.
Once the identities are squared away, the client and server go about establishing a session key for the actual encryption. So while the certificate identity stuff uses RSA, the actual session encryption generally uses AES or RC4, or Blowfish -- symmetric ciphers where the same key is used to both encrypt and decrypt. These are dramatically faster.
There's a couple of ways to go about generating a session key. How it is done depends on what features are supported by the server and browser. The older more naive approach is to simply generate a random number and send it encrypted using the public key. THe problem is that if the session is captured by an attacker who later acquires the private key, he'll be able to decrypt past sessions.
A better solution that is gaining traction uses Diffie-Hellman key negotiation to generate a shared secret that is never communicated. The negotiation still uses the asymmetric keys to ensure that the negotiated key isn't corrupted by a man-in-the-middle, but the important point is that the key never transits the wire, not can it be derived by anything that gets communicated. This means that when the connection closes and the client and server both forget the key, the data, if captured, can never be decrypted again. This topic gets plenty of attention here on this site under the moniker Perfect Forward Secrecy.
