If an encrypted connection can be compromised when a server's private key is stollen, why don't servers simply generate a new private key for each unique session. It seems like it would eliminate a point of vulnerability if it was just generated as needed.
I'm assuming that it has something to do with verifying authority chains, or performance, or something like that, but I was wondering if anyone knows for sure why it's not done that way?
When you connect to a server there are two types of encryption in play.
First, there's a public-private keypair associated with asymmetric encryption that is used to validate your identity. Typically (in the case of visiting HTTPS websites), you create a long lived pair of keys (one public and one private), submit the public key part and identifying information to a trusted certificate authority (CA), prove your identity to the certificate authority's satisfaction (e.g., verify you control the domain the certificate is being issued for), and the certificate authority signs the certificate for you. Now you post your CA-signed certificate publicly on your website. Anyone connecting to the website for the first time, whose browser/OS already trusts the CA that signed your certificate, can verify the identity of the website you are connecting to by issuing challenges to the CA-signed certificate that you can only answer if you control the websites private key. Note the certificate is only used for the authentication of identity (by relying on chain of trust with certificate authority) at the start of a conversation.
To actually transmit data, you don't use asymmetric encryption as asymmetric encryption is slow and only encrypts short messages. Symmetric encryption is much faster and work well to encrypt arbitrarily large messages quickly. For the symmetric encryption part, you use key exchange protocols like DHE to have both servers negotiate a shared symmetric key that will be used to encrypt and decrypt messages, and the key exchange protocol can negotiate a random symmetric key without actually sending the shared symmetric key over the network.
For an example of a key exchange protocol that doesn't send the full key over the network for Alice to send a message to Bob, first they both agree on two numbers generator (g) and modulus (N) and each picks a secret random number a and b (Alice generates a and Bob generates b; note Alice will never learn b and Bob will never learn a). Then Bob send a message to Alice containing Kb = g^b mod N. Alice calculates the shared secret key K = g^(ab) mod N by calculating K = Kb^a mod N. Alice uses the secret key K to symmetrically encrypt her message and sends it to Bob along with Ka = g^a mod N that Bob will need to decrypt. If a network eavesdropper Eve listens in on their messages, they see g, N, g^a mod N, g^b mod N and the encrypted message, but do not have a known feasible way to calculate K without additionally knowing a or b. This key exchange however is still vulnerable to active tampering, where Alice could try sending a message to Bob, but instead Eve pretends to be Bob. This is why in addition to forward secrecy at the start of the conversation you need Alice and Bob to identify each other (which is customarily done using the long lived certificates signed by CAs).
Forward secrecy does your suggestion of not reusing the random symmetric keys at all, but renegotiating them with each exchanged message.
