Not even that really. For a TLS 1.3 handshake (and the details for most TLS 1.2 sites visited in most browsers are morally equivalent but technically complicated) it goes like this (but the random values are much, much larger):

Client: I want to talk to www.example.com, I suggest we try x25519 key agreement and here are some symmetric algorithms I know, I have chosen a random value and as a result I now say 41389

Server: Hello, I can do x25519 key agreement and I've picked 128-bit AES GCM from your list. I also chose a random value, and as a result I say 15402.

After this point everything is encrypted with 128-bit AES GCM using a key that you'd only be able to work out if you know one of the two secret random values (because you're the Client or the Server) and the number the other party announced. Since the server spoke last, this next message might actually appear right after the last one in the same data packet...

Server: Cool, now that everything is encrypted, here is a copy of a certificate for www.example.com. That certificate has an RSA public key inside it, so now here is my RSA signature over the entire transcript of our conversation so far, proving that I, the owner of that key, was in fact the Server all along.

Client: Cool. I want to GET /index.html or whatever

Notice that the symmetric key wasn't technically "encrypted" by anybody, but instead the two parties somehow agreed on a random key despite it never being chosen by anybody or sent over the wire. This key agreement protocol is technically asymmetric cryptography, but it isn't really encryption per se. The signature used by the server to prove its identity also isn't encryption, although since an RSA key was used it is mechanically more similar to encryption than it would be in modern schemes.